625 lines
15 KiB
HTML
625 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Searching for Bugs</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
|
|
REL="HOME"
|
|
TITLE="The Bugzilla Guide - 3.4.2
|
|
Release"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Using Bugzilla"
|
|
HREF="using.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Life Cycle of a Bug"
|
|
HREF="lifecycle.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Filing Bugs"
|
|
HREF="bugreports.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Bugzilla Guide - 3.4.2
|
|
Release</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="lifecycle.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 5. Using Bugzilla</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="bugreports.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="query"
|
|
>5.5. Searching for Bugs</A
|
|
></H1
|
|
><P
|
|
>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:
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.4-branch/query.cgi"
|
|
TARGET="_top"
|
|
>http://landfill.bugzilla.org/bugzilla-3.4-branch/query.cgi</A
|
|
>.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
> 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 <A
|
|
HREF="userpreferences.html#savedsearches"
|
|
>Saved Searches</A
|
|
> for more details.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="boolean"
|
|
>5.5.1. Boolean Charts</A
|
|
></H2
|
|
><P
|
|
> Highly advanced querying is done using Boolean Charts.
|
|
</P
|
|
><P
|
|
> 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 criteria.
|
|
</P
|
|
><P
|
|
> The simplest boolean searches have only one term. These searches
|
|
permit the selected left <EM
|
|
>field</EM
|
|
>
|
|
to be compared using a
|
|
selectable <EM
|
|
>operator</EM
|
|
> to a
|
|
specified <EM
|
|
>value.</EM
|
|
>
|
|
Using the "And," "Or," and "Add Another Boolean Chart" buttons,
|
|
additional terms can be included in the query, further
|
|
altering the list of bugs returned by the query.
|
|
</P
|
|
><P
|
|
> There are three fields in each row of a boolean search.
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Field:</EM
|
|
>
|
|
the items being searched
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Operator:</EM
|
|
>
|
|
the comparison operator
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Value:</EM
|
|
>
|
|
the value to which the field is being compared
|
|
</P
|
|
></LI
|
|
></UL
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="pronouns"
|
|
>5.5.1.1. Pronoun Substitution</A
|
|
></H3
|
|
><P
|
|
> Sometimes, a query needs to compare a user-related field
|
|
(such as ReportedBy) with a role-specific user (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
|
|
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.
|
|
</P
|
|
><P
|
|
> Boolean charts also let you type a group name in any user-related
|
|
field if the operator is either "equals", "notequals" or "anyexact".
|
|
This will let you query for any member belonging (or not) to the
|
|
specified group. The group name must be entered following the
|
|
"%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 type "%group.editbugs%".
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="negation"
|
|
>5.5.1.2. Negation</A
|
|
></H3
|
|
><P
|
|
> At first glance, negation seems redundant. Rather than
|
|
searching for
|
|
<A
|
|
NAME="AEN2500"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT("summary" "contains the string" "foo"),
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
one could search for
|
|
<A
|
|
NAME="AEN2502"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("summary" "does not contain the string" "foo").
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
However, the search
|
|
<A
|
|
NAME="AEN2504"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("CC" "does not contain the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
would find every bug where anyone on the CC list did not contain
|
|
"@mozilla.org" while
|
|
<A
|
|
NAME="AEN2506"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT("CC" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
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
|
|
<A
|
|
NAME="AEN2508"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT(("product" "equals" "update") OR
|
|
("component" "equals" "Documentation"))
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
to find bugs that are neither
|
|
in the update product or in the documentation component or
|
|
<A
|
|
NAME="AEN2510"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT(("commenter" "equals" "%assignee%") OR
|
|
("component" "equals" "Documentation"))
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
to find non-documentation
|
|
bugs on which the assignee has never commented.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="multiplecharts"
|
|
>5.5.1.3. Multiple Charts</A
|
|
></H3
|
|
><P
|
|
> 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
|
|
<A
|
|
NAME="AEN2515"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("cc" "contains the string" "foo@") AND
|
|
("cc" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
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.
|
|
<A
|
|
NAME="AEN2517"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> First chart: ("cc" "contains the string" "foo@")
|
|
</P
|
|
><P
|
|
> Second chart: ("cc" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
The bugs listed will be only the bugs where ALL the charts are true.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="quicksearch"
|
|
>5.5.2. Quicksearch</A
|
|
></H2
|
|
><P
|
|
> Quicksearch is a single-text-box query tool which uses
|
|
metacharacters to indicate what is to be searched. For example, typing
|
|
"<TT
|
|
CLASS="literal"
|
|
>foo|bar</TT
|
|
>"
|
|
into Quicksearch would search for "foo" or "bar" in the
|
|
summary and status whiteboard of a bug; adding
|
|
"<TT
|
|
CLASS="literal"
|
|
>:BazProduct</TT
|
|
>" would
|
|
search only in that product.
|
|
You can use it to find a bug by its number or its alias, too.
|
|
</P
|
|
><P
|
|
> You'll find the Quicksearch box in Bugzilla's footer area.
|
|
On Bugzilla's front page, there is an additional
|
|
<A
|
|
HREF="../../page.cgi?id=quicksearch.html"
|
|
TARGET="_top"
|
|
>Help</A
|
|
>
|
|
link which details how to use it.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="casesensitivity"
|
|
>5.5.3. Case Sensitivity in Searches</A
|
|
></H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="list"
|
|
>5.5.4. Bug Lists</A
|
|
></H2
|
|
><P
|
|
>If you run a search, a list of matching bugs will be returned.
|
|
</P
|
|
><P
|
|
>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:
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Long Format:</EM
|
|
>
|
|
|
|
this gives you a large page with a non-editable summary of the fields
|
|
of each bug.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>XML:</EM
|
|
>
|
|
|
|
get the buglist in the XML format.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>CSV:</EM
|
|
>
|
|
|
|
get the buglist as comma-separated values, for import into e.g.
|
|
a spreadsheet.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Feed:</EM
|
|
>
|
|
|
|
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.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>iCalendar:</EM
|
|
>
|
|
|
|
Get the buglist as an iCalendar file. Each bug is represented as a
|
|
to-do item in the imported calendar.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Change Columns:</EM
|
|
>
|
|
|
|
change the bug attributes which appear in the list.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Change several bugs at once:</EM
|
|
>
|
|
|
|
If your account is sufficiently empowered, and more than one bug
|
|
appear in the bug list, this link is displayed which lets you make
|
|
the same change to all the bugs in the list - for example, changing
|
|
their assignee.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Send mail to bug assignees:</EM
|
|
>
|
|
|
|
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.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Edit Search:</EM
|
|
>
|
|
|
|
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.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Remember Search As:</EM
|
|
>
|
|
|
|
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.
|
|
</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
><P
|
|
> If you would like to access the bug list from another program
|
|
it is often useful to have the list returned in something other
|
|
than HTML. By adding the ctype=type parameter into the bug list URL
|
|
you can specify several alternate formats. Besides the types described
|
|
above, the following formats are also supported: ECMAScript, also known
|
|
as JavaScript (ctype=js), and Resource Description Framework RDF/XML
|
|
(ctype=rdf).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="individual-buglists"
|
|
>5.5.5. Adding/removing tags to/from bugs</A
|
|
></H2
|
|
><P
|
|
> You can add and remove tags from individual bugs, which let you find and
|
|
manage them more easily. Creating a new tag automatically generates a saved
|
|
search - whose name is the name of the tag - which lists bugs with this tag.
|
|
This saved search will be displayed in the footer of pages by default, as
|
|
all other saved searches. The main difference between tags and normal saved
|
|
searches is that saved searches, as described in the previous section, are
|
|
stored in the form of a list of matching criteria, while the saved search
|
|
generated by tags is a list of bug numbers. Consequently, you can easily
|
|
edit this list by either adding or removing tags from bugs. To enable this
|
|
feature, you have to turn on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Enable tags for bugs"</SPAN
|
|
> user
|
|
preference, see <A
|
|
HREF="userpreferences.html"
|
|
>Section 5.10</A
|
|
>. This feature is disabled
|
|
by default.
|
|
</P
|
|
><P
|
|
> This feature is useful when you want to keep track of several bugs, but
|
|
for different reasons. Instead of adding yourself to the CC list of all
|
|
these bugs and mixing all these reasons, you can now store these bugs in
|
|
separate lists, e.g. <SPAN
|
|
CLASS="QUOTE"
|
|
>"Keep in mind"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"Interesting bugs"</SPAN
|
|
>,
|
|
or <SPAN
|
|
CLASS="QUOTE"
|
|
>"Triage"</SPAN
|
|
>. One big advantage of this way to manage bugs
|
|
is that you can easily add or remove bugs one by one, which is not
|
|
possible to do with saved searches without having to edit the search
|
|
criteria again.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="lifecycle.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="bugreports.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Life Cycle of a Bug</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="using.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Filing Bugs</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |