2.5. Finding Bugs¶
Bugzilla has a number of different search options.
Note
Bugzilla queries are case-insensitive and accent-insensitive when used with either MySQL or Oracle databases. When using Bugzilla with PostgreSQL, however, some queries are case sensitive. This is due to the way PostgreSQL handles case and accent sensitivity.
2.5.1. Quicksearch¶
Quicksearch is a single-text-box query tool. You’ll find it in Bugzilla’s header or footer.
Quicksearch uses metacharacters to indicate what is to be searched. For example, typing
foo|bar
into Quicksearch would search for “foo” or “bar” in the summary and status whiteboard of a bug; adding
:BazProduct
would search only in that product.
You can also use it to go directly to a bug by entering its number or its alias.
2.5.2. Simple Search¶
Simple Search is good for finding one particular bug. It works like internet search engines - just enter some keywords and off you go.
2.5.3. Advanced Search¶
The Advanced Search page is used to produce a list of all bugs fitting exact criteria. You can play with it on Stage.
Advanced Search has controls for selecting different possible values for all of the fields in a bug, as described above. For some fields, multiple values can be selected. In those cases, Bugzilla returns bugs where the content of the field matches any one of the selected values. If none is selected, then the field can take any value.
After a search is run, you can save it as a Saved Search, which will appear in the page footer. If you are in the group defined by the “querysharegroup” parameter, you may share your queries with other users; see Saved Searches for more details.
2.5.4. Custom Search¶
Highly advanced querying is done using the Custom Search feature of the Advanced Search page.
The search criteria here further restrict the set of results returned by a query, over and above those defined in the fields at the top of the page. It is thereby possible to search for bugs based on elaborate combinations of criteria.
The simplest custom searches have only one term. These searches permit the selected field to be compared using a selectable operator to a specified value. Much of this could be reproduced using the standard fields. However, you can then combine terms using “Match ANY” or “Match ALL”, using parentheses for combining and priority, in order to construct searches of almost arbitrary complexity.
There are three fields in each row (known as a “term”) of a custom search:
- Field: the name of the field being searched
- Operator: the comparison operator
- Value: the value to which the field is being compared
The list of available fields contains all the fields defined for a bug, including any custom fields, and then also some pseudofields like Assignee Real Name, Days Since Bug Changed, Time Since Assignee Touched and other things it may be useful to search on.
There are a wide range of operators available, not all of which may make sense for a particular field. There are various string-matching operations (including regular expressions), numerical comparisons (which also work for dates), and also the ability to search for change information—when a field changed, what it changed from or to, and who did it. There are special operators for is empty and is not empty, because Bugzilla can’t tell the difference between a value field left blank on purpose and one left blank by accident.
You can have an arbitrary number of rows, and the dropdown box above them defines how they relate—Match ALL of the following separately, Match ANY of the following separately, or Match ALL of the following against the same field. The difference between the first and the third can be illustrated with a comment search. If you have a search:
Comment contains the string "Fred"
Comment contains the string "Barney"
then under the first regime (match separately) the search would return bugs where “Fred” appeared in one comment and “Barney” in the same or any other comment, whereas under the second (match against the same field), both strings would need to occur in exactly the same comment.
2.5.4.1. Advanced Features¶
If you click Show Advanced Features, then more capabilities appear. You can negate any row with a checkbox (see below) and also group lines of the search with parentheses to determine how different search terms relate. Within each bracketed set, you get the choice of combining them using ALL (i.e. AND) or ANY (i.e. OR).
2.5.4.2. Negation¶
At first glance, negation seems redundant. Rather than searching for:
NOT ( summary contains the string "foo" )
one could search for:
summary does not contain the string "foo"
However, the search:
CC does not contain the string "@mozilla.org"
would find every bug where anyone on the CC list did not contain “@mozilla.org” while:
NOT ( CC contains the string "@mozilla.org" )
would find every bug where there was nobody on the CC list who did contain the string. Similarly, the use of negation also permits complex expressions to be built using terms OR’d together and then negated. Negation permits queries such as:
NOT ( ( product equals "Update" )
OR
( component equals "Documentation" )
)
to find bugs that are neither in the Update product or in the Documentation component or:
NOT ( ( commenter equals "%assignee%" )
OR
(component equals "Documentation" )
)
to find non-documentation bugs on which the assignee has never commented.
2.5.4.3. Pronoun Substitution¶
Sometimes, a query needs to compare a user-related field (such as Reporter) with a role-specific user (such as the user running the query or the user to whom each bug is assigned). For example, you may want to find all bugs that are assigned to the person who reported them.
When the Custom Search operator is either equals or notequals, the value can be “%reporter%”, “%assignee%”, “%qacontact%”, or “%user%”. These are known as “pronouns”. The user pronoun refers to the user who is executing the query or, in the case of whining reports, the user who will be the recipient of the report. The reporter, assignee, and qacontact pronouns refer to the corresponding fields in the bug.
This feature also lets you search by a user’s group memberships. If the operator is either equals, notequals or anyexact, you can search for whether a user belongs (or not) to the specified group. The group name must be entered using “%group.foo%” syntax, where “foo” is the group name. So if you are looking for bugs reported by any user being in the “editbugs” group, then you can use:
reporter equals "%group.editbugs%"
2.5.4.4. Dates & Times¶
For date and date-time fields you can search using relative or full dates.
The recommended format for inputting dates is YYYY-MM-DD other formats can be used and should work, but this format _will_ work.
The recommended format for inputting date-times is YYYY-MM-DD HH:MM:SS other formats can be used and should work, but this format _will_ work.
For logged in users the timezone used will be the one set in the user’s preferences. For logged out users the timezone will be the one used on the server. Most servers use UTC.
Relative dates can be specified using -/+ followed by a count of durations, followed by a single letter for the time period.
- H: Hours
- D: Days
- W: Weeks
- M: Months
- Y: Years
e.g. created in the last month:
creation_ts is greater than or equal to "-1M"
e.g. Updated in the last week:
delta_ts is greater than or equal to "-1W"
2.5.5. Sort Order¶
To control the ordering of the bug list you can select an order from the drop down labeled “Sort results by”. Selecting from this list adds the order parameter to the search URL.
The order parameter takes a comma separated list of internal fields names, as well as an optional direction (ASC or DESC) to sort in.
e.g. order=assigned_to DESC, bug_status ASC, priority
If you order a bug list by clicking the column headings on the bug list page, then editing the search will set the order parameter and list the full order in the Last search order area.
The values in the order drop down have the following affects:
- Reuse same sort as last time:
- Use the same order as the last search. Can be customized on the bug list page. Order is listed below the drop down.
- Bug Number:
- Sort by: bug_id
- Importance:
- Sort by: priority, bug_severity
- Assignee:
- Sort by: assigned_to, bug_status, priority, bug_id
- Last Changed:
- Sort by: changeddate, bug_status, priority, assigned_to, bug_id
If no order is provided then the default order of bug_status, priority, assigned_to, bug_id is used.
2.5.6. Bug Lists¶
The result of a search is a list of matching bugs.
The format of the list is configurable. For example, it can be sorted by clicking the column headings. Other useful features can be accessed using the links at the bottom of the list:
- Long Format:
- this gives you a large page with a non-editable summary of the fields of each bug.
- XML (icon):
- get the buglist in an XML format.
- CSV (icon):
- get the buglist as comma-separated values, for import into e.g. a spreadsheet.
- Feed (icon):
- get the buglist as an Atom feed. Copy this link into your favorite feed reader. If you are using Firefox, you can also save the list as a live bookmark by clicking the live bookmark icon in the status bar. To limit the number of bugs in the feed, add a limit=n parameter to the URL.
- iCalendar (icon):
- Get the buglist as an iCalendar file. Each bug is represented as a to-do item in the imported calendar.
- Change Columns:
- change the bug attributes which appear in the list.
- Change Several Bugs At Once:
- If your account is sufficiently empowered, and more than one bug appears in the bug list, this link is displayed and lets you easily make the same change to all the bugs in the list - for example, changing their assignee.
- Send Mail to Bug Assignees:
- If more than one bug appear in the bug list and there are at least two distinct bug assignees, this links is displayed which lets you easily send a mail to the assignees of all bugs on the list.
- Edit Search:
- If you didn’t get exactly the results you were looking for, you can return to the Query page through this link and make small revisions to the query you just made so you get more accurate results.
- Remember Search As:
- You can give a search a name and remember it; a link will appear in your page footer giving you quick access to run it again later.
2.5.6.1. Table Legend¶
The bug list table contains a number of icons used to indicate attributes of a bug.
- Secure: A secure bug is a bug that has any groups set on it.
- Ignored: An ignored bug is a bug that you have told Bugzilla not to notify you about.
- Updated: An updated bug is a bug that you are involved in that has been updated since the last time you viewed it. “Involved” means you are one of reporter, assignee, qa contact, or you are CC’d on the bug.
- Requested: A requested bug is a bug that has flags that you are specifically requested on. i.e. needinfo or similar targeted flags.
2.5.6.2. DataTables¶
DataTables is used on bug lists to provide interactivity for users.
Row selection¶
Rows can be selected by using the standard selection processes for your Operating System. e.g. generally the same way as you select rows in a spreadsheet.
See Type: os on datatables.net.
This feature is provided by the RowGroup extension.
Column Order¶
You can change the order of columns, excluding the bug_id column, displayed in the table at anytime by dragging and dropping them.
This feature is provided by the ColReorder extension.
Edit Button¶
After selecting rows this button will be enabled. Clicking it will display the Bulk Edit form which allows making changes to all selected Bugs in one transaction.
On the Bulk Edit form you need to have a product selected to see fields that are limited by product or classification, or that have values that are specific to products or classifications. If you are not seeing a field or field values that you want to change then you may need to specify a product to see it.
Export Button¶
This button displays a drop down that allows exporting the bug lists in several formats.
This feature is provided by the RowGroup extension.
Column Visibility Button¶
This button displays a drop down that allows hiding and showing columns in the table. This is useful for having data in the table but hidden for when performing actions where you don’t need them visible.
When you select a field in Row Groups Button it will automatically be hidden, you can make it visible again using this button.
This feature is provided by the Buttons extension.
Row Groups Button¶
This button allows grouping data in the table in to visually distinct areas. It can reorder data and will rerun the search on the server to correctly order the results.
When you select a field it will automatically be hidden. you can make it visible again using the Column Visibility Button.
When you unselect a field it will automatically be unhidden.
You can select up to two fields to groups on.
This feature is provided by the RowGroup extension.
Filters Button¶
This buttons displays a modal form that allows filtering the current page of data on the client. Currently this filtering is limited to the status, product, assignee and component fields.
If you take any action that reloads the table content, such as using Row Groups of reordering the table, then the filters will be removed.
This feature is provided by the SearchPanes extension.
Save State Button¶
This button displays a modal form that allows saving the current table state to the browser’s local storage.
The following table configurations can be saved this way:
- Page Length
- Paging
- Search
- SearchPanes
- Select
- Sorting
If your browser is configured to clear local storage you will lose any states saved this way.
This feature is provided by the StateRestore extension.
Load State Button¶
This button displays a modal form that allows loading saved states from the browser’s local storage.
This feature is provided by the StateRestore extension.