The Bugzilla Guide - 2.20.1 Release
Prev | Chapter 6. Using Bugzilla | Next

# 6.5. Searching for Bugs

The Bugzilla Search page is the interface where you can find any bug report, comment, or patch currently in the Bugzilla system. You can play with it here: http://landfill.bugzilla.org/bugzilla-tip/query.cgi.

The Search page 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.

Once you've run a search, you can save it as a Saved Search, which appears in the page footer.

## 6.5.1. Boolean Charts

Highly advanced querying is done using Boolean Charts.

The boolean charts further restrict the set of results returned by a query. It is possible to search for bugs based on elaborate combinations of critera.

The simplest boolean searches have only one term. These searches permit the selected left field to be compared using a selectable operator to a specified value. Using the "And," "Or," and "Add Another Boolean Chart" buttons, additonal terms can be included in the query, further altering the list of bugs returned by the query.

There are three fields in each row of a boolean search.

- Field: the items being searched

- Operator: the comparison operator

- Value: the value to which the field is being compared

### 6.5.1.1. Pronoun Substitution

Sometimes, a query needs to compare a field containing a user's ID (such as ReportedBy) with a user's ID (such as the user running the query or the user to whom each bug is assigned). When the operator is either "equals" or "notequals", the value can be "%reporter%", "%assignee%", "%qacontact%", or "%user%." The user pronoun referes 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.

### 6.5.1.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.

### 6.5.1.3. Multiple Charts

The terms within a single row of a boolean chart are all constraints on a single piece of data. If you are looking for a bug that has two different people cc'd on it, then you need to use two boolean charts. A search for

> ("cc" "contains the string" "foo@") AND ("cc" "contains the string" "@mozilla.org")

would return only bugs with "foo@mozilla.org" on the cc list. If you wanted bugs where there is someone on the cc list containing "foo@" and someone else containing "@mozilla.org", then you would need two boolean charts.

> First chart: ("cc" "contains the string" "foo@")

> Second chart: ("cc" "contains the string" "@mozilla.org")

The bugs listed will be only the bugs where ALL the charts are true.

Prev | Home | Next
Life Cycle of a Bug | Up | Bug Lists