login form, and click the :guilabel:`Log in` button.
You are now logged in. Bugzilla uses cookies to remember you are
-logged in so, unless you have cookies disabled or your IP address changes,
+logged in, so, unless you have cookies disabled or your IP address changes,
you should not have to log in again during your session.
Attachments
===========
-You should use attachments, rather than comments, for large chunks of ASCII
-data, such as trace, debugging output files, or log files. That way, it
+Attachments are used to attach relevant files to bugs - patches, screenshots,
+test cases, debugging aids or logs, or anything else binary or too large to
+fit into a comment.
+
+You should use attachments, rather than comments, for large chunks of plain
+text data, such as trace, debugging output files, or log files. That way, it
doesn't bloat the bug for everyone who wants to read it, and cause people to
-receive fat, useless mails.
+receive large, useless mails.
You should make sure to trim screenshots. There's no need to show the
whole screen if you are pointing out a single-pixel problem.
Flags
=====
-A flag is a kind of status that can be set on bugs or attachments
-to indicate that the bugs/attachments are in a certain state.
-Each installation can define its own set of flags that can be set
-on bugs or attachments.
-
-If your installation has defined a flag, you can set or unset that flag,
-and if your administrator has enabled requesting of flags, you can submit
-a request for another user to set the flag.
-
-To set a flag, select either "+" or "-" from the drop-down menu next to
-the name of the flag in the "Flags" list. The meaning of these values are
-flag-specific and thus cannot be described in this documentation,
-but by way of example, setting a flag named "review" to "+" may indicate
-that the bug/attachment has passed review, while setting it to "-"
-may indicate that the bug/attachment has failed review.
+To set a flag, select either :guilabel:`+` or :guilabel:`-` from the drop-down
+menu next to the name of the flag in the :guilabel:`Flags` list. The meaning
+of these values are flag-specific and thus cannot be described in this
+documentation, but by way of example, setting a flag named :guilabel:`review`
+:guilabel:`+` may indicate that the bug/attachment has passed review, while
+setting it to :guilabel:`-` may indicate that the bug/attachment has failed
+review.
To unset a flag, click its drop-down menu and select the blank value.
Note that marking an attachment as obsolete automatically cancels all
pending requests for the attachment.
If your administrator has enabled requests for a flag, request a flag
-by selecting "?" from the drop-down menu and then entering the username
-of the user you want to set the flag in the text field next to the menu.
-
-A set flag appears in bug reports and on "edit attachment" pages with the
-abbreviated username of the user who set the flag prepended to the
-flag name. For example, if Jack sets a "review" flag to "+", it appears
-as Jack: review [ + ]
-
-A requested flag appears with the user who requested the flag prepended
-to the flag name and the user who has been requested to set the flag
-appended to the flag name within parentheses. For example, if Jack
-asks Jill for review, it appears as Jack: review [ ? ] (Jill).
-
-You can browse through open requests made of you and by you by selecting
-'My Requests' from the footer. You can also look at open requests limited
-by other requesters, requestees, products, components, and flag names from
-this page. Note that you can use '-' for requestee to specify flags with
-'no requestee' set.
+by selecting :guilabel:`?` from the drop-down menu and then entering the
+username of the user you want to set the flag in the text field next to the
+menu.
.. _time-tracking:
Users who belong to the group specified by the ``timetrackinggroup``
parameter have access to time-related fields. Developers can see
deadlines and estimated times to fix bugs, and can provide time spent
-on these bugs. Users who do not belong to this group can only see the deadline,
+on these bugs. Users who do not belong to this group can only see the deadline
but not edit it. Other time-related fields remain invisible to them.
At any time, a summary of the time spent by developers on bugs is
accessible either from bug lists when clicking the ``Time Summary``
button or from individual bugs when clicking the ``Summarize time``
link in the time tracking table. The :file:`summarize_time.cgi`
-page lets you view this information either per developer or per bug,
+page lets you view this information either per developer or per bug
and can be split on a month basis to have greater details on how time
is spent by developers.
As soon as a bug is marked as RESOLVED, the remaining time expected
to fix the bug is set to zero. This lets QA people set it again for
-their own usage, and it will be set to zero again when the bug will
-be marked as CLOSED.
+their own usage, and it will be set to zero again when the bug is
+marked as VERIFIED.
.. _lifecycle:
reading pleasure into the
`Bug Writing Guidelines <http://landfill.bugzilla.org/bugzilla-tip/page.cgi?id=bug-writing.html>`_.
While some of the advice is Mozilla-specific, the basic principles of
-reporting Reproducible, Specific bugs, isolating the Product you are
-using, the Version of the Product, the Component which failed, the
-Hardware Platform, and Operating System you were using at the time of
-the failure go a long way toward ensuring accurate, responsible fixes
-for the bug that bit you.
+reporting Reproducible, Specific bugs and isolating the Product you are
+using, the Version of the Product, the Component which failed, the Hardware
+Platform, and Operating System you were using at the time of the failure go a
+long way toward ensuring accurate, responsible fixes for the bug that bit you.
.. note:: If you want to file a test bug to see how Bugzilla works,
you can do it on one of our test installations on
which you are filing the bug, you can also request developers to consider
your bug in different ways (such as requesting review for the patch you
just attached, requesting your bug to block the next release of the
- product, and many other product specific requests).
+ product, and many other product-specific requests).
-#. Now is a good time to read your bug report again. Remove all mis-spellings,
- otherwise your bug may not be found by developers running queries for some
+#. Now is a good time to read your bug report again. Remove all misspellings;
+ otherwise, your bug may not be found by developers running queries for some
specific words, and so your bug would not get any attention.
Also make sure you didn't forget any important information developers
should know in order to reproduce the problem, and make sure your
Clone an Existing Bug
=====================
-Bugzilla allows you to 'clone' an existing bug. The newly created bug will
+Bugzilla allows you to "clone" an existing bug. The newly created bug will
inherit most settings from the old bug. This allows you to track similar
-concerns which require different handling in a new bug. To use this, go to
+concerns that require different handling in a new bug. To use this, go to
the bug that you want to clone, then click the :guilabel:`Clone This Bug`
link on the bug page. This will take you to the :guilabel:`Enter Bug`
page that is filled with the values that the old bug has.
Bugzilla has a number of different search options.
-.. note:: Bugzilla queries are case-insensitive and accent-insensitive, when
+.. 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.
You can also use it to go directly to a bug by entering its number or its
alias.
+.. todo:: Need to incorporate the full reference, and link it properly from
+ the GUI. https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html
+
Simple Search
=============
===============
The Advanced Search page is used to produce a list of all bugs fitting
-exactly-defined criteria. `You can play with it on
+exact criteria. `You can play with it on
Landfill <http://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced>`_.
Advanced Search has controls for selecting different possible
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 :ref:`saved-searches` for more details.
+with other users; see :ref:`saved-searches` for more details.
.. _custom-search:
Change several bugs at once:
If your account is sufficiently empowered, and more than one bug
- appear in the bug list, this link is displayed which lets you make
+ 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:
+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.
Once logged in, you can customize various aspects of
Bugzilla via the "Preferences" link in the page footer.
-The preferences are split into a number of tabs:
+The preferences are split into a number of tabs, detailed in the sections
+below.
.. _generalpreferences:
asks me to set a flag`` and ``Email me when someone
sets a flag I asked for``. These define how you want to
receive bugmail with regards to flags. Their use is quite
-straightforward; enable the checkboxes if you want Bugzilla to
+straightforward: enable the checkboxes if you want Bugzilla to
send you mail under either of the above conditions.
If you'd like to set your bugmail to something besides
To fine-tune your bugmail, decide the events for which you want
to receive bugmail; then decide if you want to receive it all
-the time (enable the checkbox for every column), or only when
+the time (enable the checkbox for every column) or only when
you have a certain relationship with a bug (enable the checkbox
-only for those columns). For example: if you didn't want to
+only for those columns). For example, if you didn't want to
receive mail when someone added themselves to the CC list, you
could uncheck all the boxes in the ``CC Field Changes``
line. As another example, if you never wanted to receive email
on bugs you reported unless the bug was resolved, you would
-un-check all boxes in the ``Reporter`` column
+uncheck all boxes in the ``Reporter`` column
except for the one on the ``The bug is resolved or
verified`` row.
==============
On this tab you can view and run any Saved Searches that you have
-created, and also any Saved Searches that other members of the group
+created, and any Saved Searches that other members of the group
defined in the :param:`querysharegroup` parameter have shared.
Saved Searches can be added to the page footer from this screen.
-If somebody is sharing a Search with a group she or he is allowed to
+If somebody is sharing a Search with a group they are allowed to
:ref:`assign users to <groups>`, the sharer may opt to have
the Search show up in the footer of the group's direct members by default.
*current* password into the ``Password``
field at the top of the page.
If you attempt to change your email address, a confirmation
-email is sent to both the old and new addresses, with a link to use to
+email is sent to both the old and new addresses with a link to use to
confirm the change. This helps to prevent account hijacking.
.. _api-keys:
API Keys
========
-API Keys allow you to give a "token" to some external software so it can log
+API keys allow you to give a "token" to some external software so it can log
in to the WebService API as you without knowing your password. You can then
revoke that token if you stop using the web service, and you don't need to
change your password everywhere.
You can create more than one API key if required. Each API key has an optional
-description which can help you record what each key is used for.
+description which can help you record what it is used for.
On this page, you can unrevoke, revoke and change the description of existing
API keys for your login. A revoked key means that it cannot be used. The
-description for purely for your information, and is optional.
+description is optional and purely for your information.
-You can also create a new API key by selecting the check box under the 'New
+You can also create a new API key by selecting the checkbox under the 'New
API key' section of the page.
.. _permissions:
Indicates user can edit all bug fields.
editclassifications
- Indicates user can create, destroy, and edit classifications.
+ Indicates user can create, destroy and edit classifications.
editcomponents
- Indicates user can create, destroy, and edit products, components,
+ Indicates user can create, destroy and edit products, components,
versions, milestones and flag types.
editkeywords
- Indicates user can create, destroy, and edit keywords.
+ Indicates user can create, destroy and edit keywords.
editusers
Indicates user can create, disable and edit users.
As well as the standard buglist, Bugzilla has two more ways of
viewing sets of bugs. These are the reports (which give different
views of the current state of the database) and charts (which plot
-the changes in particular sets of bugs over time.)
+the changes in particular sets of bugs over time).
.. _reports:
You can run either an HTML-table-based report, or a graphical
line/pie/bar-chart-based one. The two have different pages to
-define them, but are close cousins - once you've defined and
+define them but are close cousins - once you've defined and
viewed a report, you can switch between any of the different
views of the data at will.
Both report types are based on the idea of defining a set of bugs
-using the standard search interface, and then choosing some
+using the standard search interface and then choosing some
aspect of that set to plot on the horizontal and/or vertical axes.
You can also get a form of 3-dimensional report by choosing to have
multiple images or tables.
So, for example, you could use the search form to choose "all
-bugs in the WorldControl product", and then plot their severity
+bugs in the WorldControl product" and then plot their severity
against their component to see which component had had the largest
number of bad bugs reported against it.
-Once you've defined your parameters and hit "Generate Report",
+Once you've defined your parameters and hit :guilabel:`Generate Report`,
you can switch between HTML, CSV, Bar, Line and Pie. (Note: Pie
is only available if you didn't define a vertical axis, as pie
charts don't have one.) The other controls are fairly self-explanatory;
An individual line on a chart is called a data set.
All data sets are organised into categories and subcategories. The
data sets that Bugzilla defines automatically use the Product name
-as a Category and Component names as Subcategories, but there is no
-need for you to follow that naming scheme with your own charts if
-you don't want to.
+as a :guilabel:`Category` and Component names as :guilabel:`Subcategories`,
+but there is no need for you to follow that naming scheme with your own
+charts if you don't want to.
Data sets may be public or private. Everyone sees public data sets in
the list, but only their creator sees private data sets. Only
administrators can make data sets public.
No two data sets, even two private ones, can have the same set of
category, subcategory and name. So if you are creating private data
-sets, one idea is to have the Category be your username.
+sets, one idea is to have the :guilabel:`Category` be your username.
Creating Charts
---------------
You create a chart by selecting a number of data sets from the
-list, and pressing Add To List for each. In the List Of Data Sets
-To Plot, you can define the label that data set will have in the
-chart's legend, and also ask Bugzilla to Sum a number of data sets
-(e.g. you could Sum data sets representing RESOLVED, VERIFIED and
-CLOSED in a particular product to get a data set representing all
-the resolved bugs in that product.)
+list and pressing :guilabel:`Add To List` for each. In the
+:guilabel:`List Of Data Sets To Plot`, you can define the label that data
+set will have in the chart's legend and also ask Bugzilla to :guilabel:`Sum`
+a number of data sets (e.g. you could :guilabel:`Sum` data sets representing
+:guilabel:`RESOLVED`, :guilabel:`VERIFIED` and :guilabel:`CLOSED` in a
+particular product to get a data set representing all the resolved bugs in
+that product.)
If you've erroneously added a data set to the list, select it
-using the checkbox and click Remove. Once you add more than one
-data set, a "Grand Total" line
+using the checkbox and click :guilabel:`Remove`. Once you add more than one
+data set, a :guilabel:`Grand Total` line
automatically appears at the bottom of the list. If you don't want
this, simply remove it as you would remove any other line.
You may also choose to plot only over a certain date range, and
-to cumulate the results - that is, to plot each one using the
-previous one as a baseline, so the top line gives a sum of all
+to cumulate the results, that is, to plot each one using the
+previous one as a baseline so the top line gives a sum of all
the data sets. It's easier to try than to explain :-)
-Once a data set is in the list, one can also perform certain
-actions on it. For example, one can edit the
+Once a data set is in the list, you can also perform certain
+actions on it. For example, you can edit the
data set's parameters (name, frequency etc.) if it's one you
created or if you are an administrator.
-Once you are happy, click Chart This List to see the chart.
+Once you are happy, click :guilabel:`Chart This List` to see the chart.
.. _charts-new-series:
----------------------
You may also create new data sets of your own. To do this,
-click the "create a new data set" link on the Create Chart page.
-This takes you to a search-like interface where you can define
-the search that Bugzilla will plot. At the bottom of the page,
-you choose the category, sub-category and name of your new
+click the :guilabel:`create a new data set` link on the
+:guilabel:`Create Chart` page. This takes you to a search-like interface
+where you can define the search that Bugzilla will plot. At the bottom of the
+page, you choose the category, sub-category and name of your new
data set.
If you have sufficient permissions, you can make the data set public,
and reduce the frequency of data collection to less than the default
-seven days.
+of seven days.
produce less-than, U, greater-than rather than underlined text.
However, Bugzilla will automatically make hyperlinks out of certain
sorts of text in comments. For example, the text
-"http://www.bugzilla.org" will be turned into a link:
+``http://www.bugzilla.org`` will be turned into a link:
`<http://www.bugzilla.org>`_.
Other strings which get linkified in the obvious manner are:
========
If you are changing the fields on a bug, only comment if
-either you have something pertinent to say, or Bugzilla requires it.
-Otherwise, you may spam people unnecessarily with bug mail.
+either you have something pertinent to say or Bugzilla requires it.
+Otherwise, you may spam people unnecessarily with bugmail.
To take an example: a user can set up their account to filter out messages
where someone just adds themselves to the CC field of a bug
-(which happens a lot.) If you come along, add yourself to the CC field,
+(which happens a lot). If you come along, add yourself to the CC field,
and add a comment saying "Adding self to CC", then that person
gets a pointless piece of mail they would otherwise have avoided.
making a part of your comment look italic or bold in the generated HTML.
Bugzilla supports most of the structures defined by
`standard Markdown <http://daringfireball.net/projects/markdown/basics>`_,
-but does NOT support inline images and inline HTML.
+but does **not** support inline images and inline HTML.
Additionally, three Github Flavored Markdown features are supported.
having one or more Components in it.
*Version:*
- The "Version" field is usually used for versions of a product which
- have been released, and is set to indicate which versions of a
- Component have the particular problem the bug report is
- about.
+ The "Version" field usually contains the numbers or names of released
+ versions of the product. It is used to indicate the version(s) affected by
+ the bug report.
*Hardware (Platform and OS):*
These indicate the computing environment where the bug was
found.
*Importance (Priority and Severity):*
- The bug assignee uses the Priority field to prioritize his or her bugs.
- It's a good idea not to change this on other people's bugs. The default
- values are P1 to P5.
+ The Priority field is used to prioritize bugs, either by the assignee,
+ or someone else with authority to direct their time such as a project
+ manager. It's a good idea not to change this on other people's bugs. The
+ default values are P1 to P5.
The Severity field indicates how severe the problem is - from blocker
("application unusable") to trivial ("minor cosmetic issue"). You
on), or this bug stops other bugs being fixed (blocks), their
numbers are recorded here.
- Clicking the ``Dependency tree`` link shows
+ Clicking the :guilabel:`Dependency tree` link shows
the dependency relationships of the bug as a tree structure.
You can change how much depth to show, and you can hide resolved bugs
- from this page. You can also collaps/expand dependencies for
+ from this page. You can also collapse/expand dependencies for
each non-terminal bug on the tree view, using the [-]/[+] buttons that
appear before the summary.
The date and time the bug was last changed.
*CC List:*
- A list of people who get mail when the bug changes.
+ A list of people who get mail when the bug changes, in addition to the
+ Reporter, Assignee and QA Contact (if enabled).
*Ignore Bug Mail:*
- Set this if you want never to get bug mail from this bug again.
+ Set this if you want never to get bugmail from this bug again. See also
+ :ref:`emailpreferences`.
*\*See Also:*
- Bugs, in this Bugzilla or other Bugzillas or bug trackers, which are
+ Bugs, in this Bugzilla, other Bugzillas, or other bug trackers, that are
related to this one.
*Flags:*
*\*Time Tracking:*
This form can be used for time tracking.
- To use this feature, you have to be blessed group membership
- specified by the ``timetrackinggroup`` parameter. See :ref:`time-tracking`
- for more information.
+ To use this feature, you have to be a member of the group
+ specified by the :param:`timetrackinggroup` parameter. See
+ :ref:`time-tracking` for more information.
Orig. Est.:
This field shows the original estimated time.
This field shows the deadline for this bug.
*Attachments:*
- You can attach files (e.g. testcases or patches) to bugs. If there
+ You can attach files (e.g. test cases or patches) to bugs. If there
are any attachments, they are listed in this section. See
:ref:`attachments` for more information.
the flag itself, but contextually they could mean pass/fail,
accept/reject, approved/denied, or even a simple yes/no. If your site
allows requestable flags, then users may set a flag to ``?`` as a
-request to another user that they look at the bug/attachment, and set
+request to another user that they look at the bug/attachment and set
the flag to its correct status.
+A set flag appears in bug reports and on "edit attachment" pages with the
+abbreviated username of the user who set the flag prepended to the
+flag name. For example, if Jack sets a "review" flag to ``+``, it appears
+as :guilabel:`Jack: review [ + ]`.
+
+A requested flag appears with the user who requested the flag prepended
+to the flag name and the user who has been requested to set the flag
+appended to the flag name within parentheses. For example, if Jack
+asks Jill for review, it appears as :guilabel:`Jack: review [ ? ] (Jill)`.
+
+You can browse through open requests made of you and by you by selecting
+:guilabel:`My Requests` from the footer. You can also look at open requests
+limited by other requesters, requestees, products, components, and flag names.
+Note that you can use '-' for requestee to specify flags with no requestee
+set.
+
.. _flags-simpleexample:
A Simple Example
They might want to do this for a *lot* of bugs,
so they decide to streamline the process. So:
-#. The Bugzilla administrator creates a flag type called
- ``blocking2.0`` that shows up on all bugs in
- your product.
- It shows up on the :guilabel:`Show Bug` screen
- as the text ``blocking2.0`` with a drop-down box next
- to it. The drop-down box contains four values: an empty space,
- ``?``, ``-``, and ``+``.
+#. The Bugzilla administrator creates a flag type called blocking2.0 for bugs
+ in your product. It shows up on the :guilabel:`Show Bug` screen as the text
+ :guilabel:`blocking2.0` with a drop-down box next to it. The drop-down box
+ contains four values: an empty space, ``?``, ``-``, and ``+``.
#. The developer sets the flag to ``?``.
-#. The manager sees the ``blocking2.0``
+#. The manager sees the :guilabel:`blocking2.0`
flag with a ``?`` value.
#. If the manager thinks the feature should go into the product
- before version 2.0 can be released, he sets the flag to
- ``+``. Otherwise, he sets it to ``-``.
+ before version 2.0 can be released, they set the flag to
+ ``+``. Otherwise, they set it to ``-``.
#. Now, every Bugzilla user who looks at the bug knows whether or
not the bug needs to be fixed before release of version 2.0.
Flag Requests
-------------
-If a flag has been defined as 'requestable', and a user has enough privileges
-to request it (see below), the user can set the flag's status to ``?``.
-This status indicates that someone (a.k.a. "the requester") is asking
+If a flag has been defined as :guilabel:`requestable`, and a user has enough
+privileges to request it (see below), the user can set the flag's status to
+``?``. This status indicates that someone (a.k.a. "the requester") is asking
someone else to set the flag to either ``+`` or ``-``.
-If a flag has been defined as 'specifically requestable',
+If a flag has been defined as :guilabel:`specifically requestable`,
a text box will appear next to the flag into which the requester may
enter a Bugzilla username. That named person (a.k.a. "the requestee")
will receive an email notifying them of the request, and pointing them
to the bug/attachment in question.
-If a flag has *not* been defined as 'specifically requestable',
-then no such text-box will appear. A request to set this flag cannot be made
-of any specific individual, but must be asked "to the wind".
-A requester may "ask the wind" on any flag simply by leaving the text-box
-blank.
+If a flag has *not* been defined as :guilabel:`specifically requestable`,
+then no such text box will appear. A request to set this flag cannot be made
+of any specific individual; these requests are open for anyone to answer. In
+Bugzilla this is known as "asking the wind". A requester may ask the wind on
+any flag simply by leaving the text box blank.
.. _flag-types:
attachment on a bug.
Many Bugzilla installations use this to
-request that one developer ``review`` another
+request that one developer review another
developer's code before they check it in. They attach the code to
a bug report, and then set a flag on that attachment called
-``review`` to
-``review? reviewer@example.com``.
+:guilabel:`review` to
+:guilabel:`review? reviewer@example.com`.
reviewer\@example.com is then notified by email that
-he has to check out that attachment and approve it or deny it.
+they have to check out that attachment and approve it or deny it.
For a Bugzilla user, attachment flags show up in three places:
projects / thirdparty / bugzilla.git / commitdiff
