summaryrefslogtreecommitdiffstats
path: root/docs/en/rst/using.rst
diff options
context:
space:
mode:
authorGervase Markham <gerv@gerv.net>2014-01-17 11:15:14 +0100
committerGervase Markham <gerv@mozilla.org>2014-01-17 11:15:14 +0100
commit4105a4885d093295c71dd5d08e160b3e6cc7ee0f (patch)
tree317a067c7ca5d1556ba9208f358403cb996b48b2 /docs/en/rst/using.rst
parent22c96de30e07d73456cb336896f9c483f8790b8d (diff)
downloadbugzilla-4105a4885d093295c71dd5d08e160b3e6cc7ee0f.tar.gz
bugzilla-4105a4885d093295c71dd5d08e160b3e6cc7ee0f.tar.xz
Bug 912064 - convert docs to ReStructured Text (.rst) format. r,a=justdave.
Diffstat (limited to 'docs/en/rst/using.rst')
-rw-r--r--docs/en/rst/using.rst1375
1 files changed, 1375 insertions, 0 deletions
diff --git a/docs/en/rst/using.rst b/docs/en/rst/using.rst
new file mode 100644
index 000000000..e5a16bfcb
--- /dev/null
+++ b/docs/en/rst/using.rst
@@ -0,0 +1,1375 @@
+
+
+.. _using:
+
+==============
+Using Bugzilla
+==============
+
+.. _using-intro:
+
+Introduction
+############
+
+This section contains information for end-users of Bugzilla. There
+is a Bugzilla test installation, called
+`Landfill <http://landfill.bugzilla.org/>`_, which you are
+welcome to play with (if it's up). However, not all of the Bugzilla
+installations there will necessarily have all Bugzilla features enabled,
+and different installations run different versions, so some things may not
+quite work as this document describes.
+
+Frequently Asked Questions (FAQ) are available and answered on
+`wiki.mozilla.org <http://wiki.mozilla.org/Bugzilla:FAQ>`_.
+They may cover some questions you have which are left unanswered.
+
+.. _myaccount:
+
+Create a Bugzilla Account
+#########################
+
+If you want to use Bugzilla, first you need to create an account.
+Consult with the administrator responsible for your installation of
+Bugzilla for the URL you should use to access it. If you're
+test-driving Bugzilla, use this URL:
+`<|landfillbase|>`_.
+
+#. On the home page :file:`index.cgi`, click the
+ ``Open a new Bugzilla account`` link, or the
+ ``New Account`` link available in the footer of pages.
+ Now enter your email address, then click the ``Send``
+ button.
+
+ .. note:: If none of these links is available, this means that the
+ administrator of the installation has disabled self-registration.
+ This means that only an administrator can create accounts
+ for other users. One reason could be that this installation is
+ private.
+
+ .. note:: Also, if only some users are allowed to create an account on
+ the installation, you may see these links but your registration
+ may fail if your email address doesn't match the ones accepted
+ by the installation. This is another way to restrict who can
+ access and edit bugs in this installation.
+
+#. Within moments, and if your registration is accepted, you should
+ receive an email to the address you provided, which contains your
+ login name (generally the same as the email address), and two URLs
+ with a token (a random string generated by the installation) to
+ confirm, respectively cancel, your registration. This is a way to
+ prevent users from abusing the generation of user accounts, for
+ instance by entering inexistent email addresses, or email addresses
+ which do not belong to them.
+
+#. By default, you have 3 days to confirm your registration. Past this
+ timeframe, the token is invalidated and the registration is
+ automatically canceled. You can also cancel this registration sooner
+ by using the appropriate URL in the email you got.
+
+#. If you confirm your registration, Bugzilla will ask you your real name
+ (optional, but recommended) and your password, which must be between
+ 3 and 16 characters long.
+
+#. Now all you need to do is to click the ``Log In``
+ link in the footer at the bottom of the page in your browser,
+ enter your email address and password you just chose into the
+ login form, and click the ``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,
+you should not have to log in again during your session.
+
+.. _bug_page:
+
+Anatomy of a Bug
+################
+
+The core of Bugzilla is the screen which displays a particular
+bug. It's a good place to explain some Bugzilla concepts.
+`Bug 1 on Landfill <|landfillbase|show_bug.cgi?id=1>`_
+is a good example. Note that the labels for most fields are hyperlinks;
+clicking them will take you to context-sensitive help on that
+particular field. Fields marked * may not be present on every
+installation of Bugzilla.
+
+#. *Product and Component*:
+ Bugs are divided up by Product and Component, with a Product
+ having one or more Components in it. For example,
+ bugzilla.mozilla.org's "Bugzilla" Product is composed of several
+ Components:
+
+ Administration:
+ Administration of a Bugzilla installation.
+ Bugzilla-General:
+ Anything that doesn't fit in the other components, or spans
+ multiple components.
+ Creating/Changing Bugs:
+ Creating, changing, and viewing bugs.
+ Documentation:
+ The Bugzilla documentation, including The Bugzilla Guide.
+ Email:
+ Anything to do with email sent by Bugzilla.
+ Installation:
+ The installation process of Bugzilla.
+ Query/Buglist:
+ Anything to do with searching for bugs and viewing the
+ buglists.
+ Reporting/Charting:
+ Getting reports from Bugzilla.
+ User Accounts:
+ Anything about managing a user account from the user's perspective.
+ Saved queries, creating accounts, changing passwords, logging in,
+ etc.
+ User Interface:
+ General issues having to do with the user interface cosmetics (not
+ functionality) including cosmetic issues, HTML templates,
+ etc.
+
+#. *Status and Resolution:*
+ These define exactly what state the bug is in - from not even
+ being confirmed as a bug, through to being fixed and the fix
+ confirmed by Quality Assurance. The different possible values for
+ Status and Resolution on your installation should be documented in the
+ context-sensitive help for those items.
+
+#. *Assigned To:*
+ The person responsible for fixing the bug.
+
+#. *\*QA Contact:*
+ The person responsible for quality assurance on this bug.
+
+#. *\*URL:*
+ A URL associated with the bug, if any.
+
+#. *Summary:*
+ A one-sentence summary of the problem.
+
+#. *\*Status Whiteboard:*
+ (a.k.a. Whiteboard) A free-form text area for adding short notes
+ and tags to a bug.
+
+#. *\*Keywords:*
+ The administrator can define keywords which you can use to tag and
+ categorise bugs - e.g. The Mozilla Project has keywords like crash
+ and regression.
+
+#. *Platform and OS:*
+ These indicate the computing environment where the bug was
+ found.
+
+#. *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.
+
+#. *Priority:*
+ The bug assignee uses this field to prioritize his or her bugs.
+ It's a good idea not to change this on other people's bugs.
+
+#. *Severity:*
+ This indicates how severe the problem is - from blocker
+ ("application unusable") to trivial ("minor cosmetic issue"). You
+ can also use this field to indicate whether a bug is an enhancement
+ request.
+
+#. *\*Target:*
+ (a.k.a. Target Milestone) A future version by which the bug is to
+ be fixed. e.g. The Bugzilla Project's milestones for future
+ Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not
+ restricted to numbers, thought - you can use any text strings, such
+ as dates.
+
+#. *Reporter:*
+ The person who filed the bug.
+
+#. *CC list:*
+ A list of people who get mail when the bug changes.
+
+#. *\*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.
+
+ Orig. Est.:
+ This field shows the original estimated time.
+ Current Est.:
+ This field shows the current estimated time.
+ This number is calculated from ``Hours Worked``
+ and ``Hours Left``.
+ Hours Worked:
+ This field shows the number of hours worked.
+ Hours Left:
+ This field shows the ``Current Est.`` -
+ ``Hours Worked``.
+ This value + ``Hours Worked`` will become the
+ new Current Est.
+ %Complete:
+ This field shows what percentage of the task is complete.
+ Gain:
+ This field shows the number of hours that the bug is ahead of the
+ ``Orig. Est.``.
+ Deadline:
+ This field shows the deadline for this bug.
+
+#. *Attachments:*
+ You can attach files (e.g. testcases or patches) to bugs. If there
+ are any attachments, they are listed in this section.
+
+#. *\*Dependencies:*
+ If this bug cannot be fixed unless other bugs are fixed (depends
+ on), or this bug stops other bugs being fixed (blocks), their
+ numbers are recorded here.
+
+#. *\*Votes:*
+ Whether this bug has any votes.
+
+#. *Additional Comments:*
+ You can add your two cents to the bug discussion here, if you have
+ something worthwhile to say.
+
+.. _lifecycle:
+
+Life Cycle of a Bug
+###################
+
+The life cycle of a bug, also known as workflow, is customizable to match
+the needs of your organization, see :ref:`bug_status_workflow`.
+:ref:`lifecycle-image` contains a graphical representation of
+the default workflow using the default bug statuses. If you wish to
+customize this image for your site, the
+`diagram file <../images/bzLifecycle.xml>`_
+is available in `Dia's <http://www.gnome.org/projects/dia>`_
+native XML format.
+
+.. _lifecycle-image:
+
+Lifecycle of a Bugzilla Bug
+===========================
+
+.. image:: ../images/bzLifecycle.png
+
+.. _query:
+
+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:
+`<|landfillbase|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.
+
+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:`savedsearches` for more details.
+
+.. _boolean:
+
+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 criteria.
+
+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,
+additional 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
+
+.. _pronouns:
+
+Pronoun Substitution
+--------------------
+
+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.
+
+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%".
+
+.. _negation:
+
+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.
+
+.. _multiplecharts:
+
+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.
+
+.. _quicksearch:
+
+Quicksearch
+===========
+
+Quicksearch is a single-text-box query tool which 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 use it to find a bug by its number or its alias, too.
+
+You'll find the Quicksearch box in Bugzilla's footer area.
+On Bugzilla's front page, there is an additional
+`Help <../../page.cgi?id=quicksearch.html>`_
+link which details how to use it.
+
+.. _casesensitivity:
+
+Case Sensitivity in Searches
+============================
+
+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.
+
+.. _list:
+
+Bug Lists
+=========
+
+If you run a search, a list of matching bugs will be returned.
+
+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:
+ get the buglist in the XML format.
+
+CSV:
+ get the buglist as comma-separated values, for import into e.g.
+ a spreadsheet.
+
+Feed:
+ 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:
+ 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
+ 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.
+
+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.
+
+.. _individual-buglists:
+
+Adding/removing tags to/from bugs
+=================================
+
+You can add and remove tags from individual bugs, which let you find and
+manage bugs more easily. Tags are per-user and so are only visible and editable
+by the user who created them. You can then run queries using tags as a criteria,
+either by using the Advanced Search form, or simply by typing "tag:my_tag_name"
+in the QuickSearch box at the top (or bottom) of the page. Tags can also be
+displayed in buglists.
+
+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. ``Keep in mind``, ``Interesting bugs``,
+or ``Triage``. One big advantage of this way to manage bugs
+is that you can easily add or remove tags from bugs one by one.
+
+.. _bugreports:
+
+Filing Bugs
+###########
+
+.. _fillingbugs:
+
+Reporting a New Bug
+===================
+
+Years of bug writing experience has been distilled for your
+reading pleasure into the
+`Bug Writing Guidelines <|landfillbase|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.
+
+The procedure for filing a bug is as follows:
+
+#. Click the ``New`` link available in the footer
+ of pages, or the ``Enter a new bug report`` link
+ displayed on the home page of the Bugzilla installation.
+
+ .. 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
+ `the Landfill server <|landfillbase|>`_.
+
+#. You first have to select the product in which you found a bug.
+
+#. You now see a form where you can specify the component (part of
+ the product which is affected by the bug you discovered; if you have
+ no idea, just select ``General`` if such a component exists),
+ the version of the program you were using, the Operating System and
+ platform your program is running on and the severity of the bug (if the
+ bug you found crashes the program, it's probably a major or a critical
+ bug; if it's a typo somewhere, that's something pretty minor; if it's
+ something you would like to see implemented, then that's an enhancement).
+
+#. You now have to give a short but descriptive summary of the bug you found.
+ ``My program is crashing all the time`` is a very poor summary
+ and doesn't help developers at all. Try something more meaningful or
+ your bug will probably be ignored due to a lack of precision.
+ The next step is to give a very detailed list of steps to reproduce
+ the problem you encountered. Try to limit these steps to a minimum set
+ required to reproduce the problem. This will make the life of
+ developers easier, and the probability that they consider your bug in
+ a reasonable timeframe will be much higher.
+
+ .. note:: Try to make sure that everything in the summary is also in the first
+ comment. Summaries are often updated and this will ensure your original
+ information is easily accessible.
+
+#. As you file the bug, you can also attach a document (testcase, patch,
+ or screenshot of the problem).
+
+#. Depending on the Bugzilla installation you are using and the product in
+ 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).
+
+#. 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
+ description of the problem is explicit and clear enough.
+ When you think your bug report is ready to go, the last step is to
+ click the ``Commit`` button to add your report into the database.
+
+You do not need to put "any" or similar strings in the URL field.
+If there is no specific URL associated with the bug, leave this
+field blank.
+
+If you feel a bug you filed was incorrectly marked as a
+DUPLICATE of another, please question it in your bug, not
+the bug it was duped to. Feel free to CC the person who duped it
+if they are not already CCed.
+
+.. _cloningbugs:
+
+Clone an Existing Bug
+=====================
+
+Starting with version 2.20, Bugzilla has a feature that allows you
+to clone an existing bug. The newly created bug will inherit
+most settings from the old bug. This allows you to track more
+easily similar concerns in a new bug. To use this, go to the bug
+that you want to clone, then click the ``Clone This Bug``
+link on the bug page. This will take you to the ``Enter Bug``
+page that is filled with the values that the old bug has.
+You can change those values and/or texts if needed.
+
+.. _attachments:
+
+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
+doesn't bloat the bug for everyone who wants to read it, and cause people to
+receive fat, 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.
+
+Bugzilla stores and uses a Content-Type for each attachment
+(e.g. text/html). To download an attachment as a different
+Content-Type (e.g. application/xhtml+xml), you can override this
+using a 'content_type' parameter on the URL, e.g.
+:file:`&content_type=text/plain`.
+
+Also, you can enter the URL pointing to the attachment instead of
+uploading the attachment itself. For example, this is useful if you want to
+point to an external application, a website or a very large file. Note that
+there is no guarantee that the source file will always be available, nor
+that its content will remain unchanged.
+
+Another way to attach data is to paste text directly in the text field,
+and Bugzilla will convert it into an attachment. This is pretty useful
+when you do copy and paste, and you don't want to put the text in a temporary
+file first.
+
+.. _patchviewer:
+
+Patch Viewer
+============
+
+Viewing and reviewing patches in Bugzilla is often difficult due to
+lack of context, improper format and the inherent readability issues that
+raw patches present. Patch Viewer is an enhancement to Bugzilla designed
+to fix that by offering increased context, linking to sections, and
+integrating with Bonsai, LXR and CVS.
+
+Patch viewer allows you to:
+
++ View patches in color, with side-by-side view rather than trying
+ to interpret the contents of the patch.
+
++ See the difference between two patches.
+
++ Get more context in a patch.
+
++ Collapse and expand sections of a patch for easy
+ reading.
+
++ Link to a particular section of a patch for discussion or
+ review
+
++ Go to Bonsai or LXR to see more context, blame, and
+ cross-references for the part of the patch you are looking at
+
++ Create a rawtext unified format diff out of any patch, no
+ matter what format it came from
+
+.. _patchviewer_view:
+
+Viewing Patches in Patch Viewer
+-------------------------------
+
+The main way to view a patch in patch viewer is to click on the
+"Diff" link next to a patch in the Attachments list on a bug. You may
+also do this within the edit window by clicking the "View Attachment As
+Diff" button in the Edit Attachment screen.
+
+.. _patchviewer_diff:
+
+Seeing the Difference Between Two Patches
+-----------------------------------------
+
+To see the difference between two patches, you must first view the
+newer patch in Patch Viewer. Then select the older patch from the
+dropdown at the top of the page ("Differences between \[dropdown] and
+this patch") and click the "Diff" button. This will show you what
+is new or changed in the newer patch.
+
+.. _patchviewer_context:
+
+Getting More Context in a Patch
+-------------------------------
+
+To get more context in a patch, you put a number in the textbox at
+the top of Patch Viewer ("Patch / File / \[textbox]") and hit enter.
+This will give you that many lines of context before and after each
+change. Alternatively, you can click on the "File" link there and it
+will show each change in the full context of the file. This feature only
+works against files that were diffed using "cvs diff".
+
+.. _patchviewer_collapse:
+
+Collapsing and Expanding Sections of a Patch
+--------------------------------------------
+
+To view only a certain set of files in a patch (for example, if a
+patch is absolutely huge and you want to only review part of it at a
+time), you can click the "(+)" and "(-)" links next to each file (to
+expand it or collapse it). If you want to collapse all files or expand
+all files, you can click the "Collapse All" and "Expand All" links at the
+top of the page.
+
+.. _patchviewer_link:
+
+Linking to a Section of a Patch
+-------------------------------
+
+To link to a section of a patch (for example, if you want to be
+able to give someone a URL to show them which part you are talking
+about) you simply click the "Link Here" link on the section header. The
+resulting URL can be copied and used in discussion.
+
+.. _patchviewer_bonsai_lxr:
+
+Going to Bonsai and LXR
+-----------------------
+
+To go to Bonsai to get blame for the lines you are interested in,
+you can click the "Lines XX-YY" link on the section header you are
+interested in. This works even if the patch is against an old
+version of the file, since Bonsai stores all versions of the file.
+
+To go to LXR, you click on the filename on the file header
+(unfortunately, since LXR only does the most recent version, line
+numbers are likely to rot).
+
+.. _patchviewer_unified_diff:
+
+Creating a Unified Diff
+-----------------------
+
+If the patch is not in a format that you like, you can turn it
+into a unified diff format by clicking the "Raw Unified" link at the top
+of the page.
+
+.. _hintsandtips:
+
+Hints and Tips
+##############
+
+This section distills some Bugzilla tips and best practices
+that have been developed.
+
+Autolinkification
+=================
+
+Bugzilla comments are plain text - so typing <U> will
+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>`_.
+Other strings which get linkified in the obvious manner are:
+
++ bug 12345
+
++ comment 7
+
++ bug 23456, comment 53
+
++ attachment 4321
+
++ mailto:george@example.com
+
++ george@example.com
+
++ ftp://ftp.mozilla.org
+
++ Most other sorts of URL
+
+A corollary here is that if you type a bug number in a comment,
+you should put the word "bug" before it, so it gets autolinkified
+for the convenience of others.
+
+.. _commenting:
+
+Comments
+========
+
+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.
+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,
+and add a comment saying "Adding self to CC", then that person
+gets a pointless piece of mail they would otherwise have avoided.
+
+Don't use sigs in comments. Signing your name ("Bill") is acceptable,
+if you do it out of habit, but full mail/news-style
+four line ASCII art creations are not.
+
+.. _comment-wrapping:
+
+Server-Side Comment Wrapping
+============================
+
+Bugzilla stores comments unwrapped and wraps them at display time. This
+ensures proper wrapping in all browsers. Lines beginning with the ">"
+character are assumed to be quotes, and are not wrapped.
+
+.. _dependencytree:
+
+Dependency Tree
+===============
+
+On the ``Dependency tree`` page linked from each bug
+page, you can see the dependency relationship from 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
+each bug on the tree view, using the \[-]/\[+] buttons that appear
+before its summary. This option is not available for terminal
+bugs in the tree (that don't have further dependencies).
+
+.. _timetracking:
+
+Time Tracking Information
+#########################
+
+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,
+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,
+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.
+
+.. _userpreferences:
+
+User Preferences
+################
+
+Once logged in, you can customize various aspects of
+Bugzilla via the "Preferences" link in the page footer.
+The preferences are split into five tabs:
+
+.. _generalpreferences:
+
+General Preferences
+===================
+
+This tab allows you to change several default settings of Bugzilla.
+
+- Bugzilla's general appearance (skin) - select which skin to use.
+ Bugzilla supports adding custom skins.
+
+- Quote the associated comment when you click on its reply link - sets
+ the behavior of the comment "Reply" link. Options include quoting the
+ full comment, just reference the comment number, or turn the link off.
+
+- Language used in email - select which language email will be sent in,
+ from the list of available languages.
+
+- After changing a bug - This controls what page is displayed after
+ changes to a bug are submitted. The options include to show the bug
+ just modified, to show the next bug in your list, or to do nothing.
+
+- Enable tags for bugs - turn bug tagging on or off.
+
+- Zoom textareas large when in use (requires JavaScript) - enable or
+ disable the automatic expanding of text areas when text is being
+ entered into them.
+
+- Field separator character for CSV files -
+ Select between a comma and semi-colon for exported CSV bug lists.
+
+- Automatically add me to the CC list of bugs I change - set default
+ behavior of CC list. Options include "Always", "Never", and "Only
+ if I have no role on them".
+
+- When viewing a bug, show comments in this order -
+ controls the order of comments. Options include "Oldest
+ to Newest", "Newest to Oldest" and "Newest to Oldest, but keep the
+ bug description at the top".
+
+- Show a quip at the top of each bug list - controls
+ whether a quip will be shown on the Bug list page.
+
+.. _emailpreferences:
+
+Email Preferences
+=================
+
+This tab allows you to enable or disable email notification on
+specific events.
+
+In general, users have almost complete control over how much (or
+how little) email Bugzilla sends them. If you want to receive the
+maximum amount of email possible, click the ``Enable All
+Mail`` button. If you don't want to receive any email from
+Bugzilla at all, click the ``Disable All Mail`` button.
+
+.. note:: A Bugzilla administrator can stop a user from receiving
+ bugmail by clicking the ``Bugmail Disabled`` checkbox
+ when editing the user account. This is a drastic step
+ best taken only for disabled accounts, as it overrides
+ the user's individual mail preferences.
+
+There are two global options -- ``Email me when someone
+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
+send you mail under either of the above conditions.
+
+If you'd like to set your bugmail to something besides
+'Completely ON' and 'Completely OFF', the
+``Field/recipient specific options`` table
+allows you to do just that. The rows of the table
+define events that can happen to a bug -- things like
+attachments being added, new comments being made, the
+priority changing, etc. The columns in the table define
+your relationship with the bug:
+
+- Reporter - Where you are the person who initially
+ reported the bug. Your name/account appears in the
+ ``Reporter:`` field.
+
+- Assignee - Where you are the person who has been
+ designated as the one responsible for the bug. Your
+ name/account appears in the ``Assigned To:``
+ field of the bug.
+
+- QA Contact - You are one of the designated
+ QA Contacts for the bug. Your account appears in the
+ ``QA Contact:`` text-box of the bug.
+
+- CC - You are on the list CC List for the bug.
+ Your account appears in the ``CC:`` text box
+ of the bug.
+
+- Voter - You have placed one or more votes for the bug.
+ Your account appears only if someone clicks on the
+ ``Show votes for this bug`` link on the bug.
+
+.. note:: Some columns may not be visible for your installation, depending
+ on your site's configuration.
+
+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
+you have a certain relationship with a bug (enable the checkbox
+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
+except for the one on the ``The bug is resolved or
+verified`` row.
+
+.. note:: Bugzilla adds the ``X-Bugzilla-Reason`` header to
+ all bugmail it sends, describing the recipient's relationship
+ (AssignedTo, Reporter, QAContact, CC, or Voter) to the bug.
+ This header can be used to do further client-side filtering.
+
+Bugzilla has a feature called ``Users Watching``.
+When you enter one or more comma-delineated user accounts (usually email
+addresses) into the text entry box, you will receive a copy of all the
+bugmail those users are sent (security settings permitting).
+This powerful functionality enables seamless transitions as developers
+change projects or users go on holiday.
+
+.. note:: The ability to watch other users may not be available in all
+ Bugzilla installations. If you don't see this feature, and feel
+ that you need it, speak to your administrator.
+
+Each user listed in the ``Users watching you`` field
+has you listed in their ``Users to watch`` list
+and can get bugmail according to your relationship to the bug and
+their ``Field/recipient specific options`` setting.
+
+.. _savedsearches:
+
+Saved Searches
+==============
+
+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
+defined in the "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
+: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.
+
+.. _accountpreferences:
+
+Name and Password
+=================
+
+On this tab, you can change your basic account information,
+including your password, email address and real name. For security
+reasons, in order to change anything on this page you must type your
+*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
+confirm the change. This helps to prevent account hijacking.
+
+.. _permissionsettings:
+
+Permissions
+===========
+
+This is a purely informative page which outlines your current
+permissions on this installation of Bugzilla.
+
+A complete list of permissions is below. Only users with
+*editusers* privileges can change the permissions
+of other users.
+
+admin
+ Indicates user is an Administrator.
+
+bz_canusewhineatothers
+ Indicates user can configure whine reports for other users.
+
+bz_canusewhines
+ Indicates user can configure whine reports for self.
+
+bz_quip_moderators
+ Indicates user can moderate quips.
+
+bz_sudoers
+ Indicates user can perform actions as other users.
+
+bz_sudo_protect
+ Indicates user cannot be impersonated by other users.
+
+canconfirm
+ Indicates user can confirm a bug or mark it a duplicate.
+
+creategroups
+ Indicates user can create and destroy groups.
+
+editbugs
+ Indicates user can edit all bug fields.
+
+editclassifications
+ Indicates user can create, destroy, and edit classifications.
+
+editcomponents
+ Indicates user can create, destroy, and edit components.
+
+editkeywords
+ Indicates user can create, destroy, and edit keywords.
+
+editusers
+ Indicates user can edit or disable users.
+
+tweakparams
+ Indicates user can change Parameters.
+
+.. note:: For more information on how permissions work in Bugzilla (i.e. who can
+ change what), see :ref:`cust-change-permissions`.
+
+.. _reporting:
+
+Reports and Charts
+##################
+
+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.)
+
+.. _reports:
+
+Reports
+=======
+
+A report is a view of the current state of the bug database.
+
+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
+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
+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
+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",
+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;
+you can change the size of the image if you find text is overwriting
+other text, or the bars are too thin to see.
+
+.. _charts:
+
+Charts
+======
+
+A chart is a view of the state of the bug database over time.
+
+Bugzilla currently has two charting systems - Old Charts and New
+Charts. Old Charts have been part of Bugzilla for a long time; they
+chart each status and resolution for each product, and that's all.
+They are deprecated, and going away soon - we won't say any more
+about them.
+New Charts are the future - they allow you to chart anything you
+can define as a search.
+
+.. note:: Both charting forms require the administrator to set up the
+ data-gathering script. If you can't see any charts, ask them whether
+ they have done so.
+
+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.
+
+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.
+
+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.)
+
+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
+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
+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
+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.
+
+.. _charts-new-series:
+
+Creating New Data Sets
+----------------------
+
+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
+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.
+
+.. _flags:
+
+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 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.
+
+.. _whining:
+
+Whining
+#######
+
+Whining is a feature in Bugzilla that can regularly annoy users at
+specified times. Using this feature, users can execute saved searches
+at specific times (i.e. the 15th of the month at midnight) or at
+regular intervals (i.e. every 15 minutes on Sundays). The results of the
+searches are sent to the user, either as a single email or as one email
+per bug, along with some descriptive text.
+
+.. warning:: Throughout this section it will be assumed that all users are members
+ of the bz_canusewhines group, membership in which is required in order
+ to use the Whining system. You can easily make all users members of
+ the bz_canusewhines group by setting the User RegExp to ".*" (without
+ the quotes).
+
+ Also worth noting is the bz_canusewhineatothers group. Members of this
+ group can create whines for any user or group in Bugzilla using a
+ extended form of the whining interface. Features only available to
+ members of the bz_canusewhineatothers group will be noted in the
+ appropriate places.
+
+.. note:: For whining to work, a special Perl script must be executed at regular
+ intervals. More information on this is available in :ref:`installation-whining`.
+
+.. note:: This section does not cover the whineatnews.pl script.
+ See :ref:`installation-whining-cron` for more information on
+ The Whining Cron.
+
+.. _whining-overview:
+
+The Event
+=========
+
+The whining system defines an "Event" as one or more queries being
+executed at regular intervals, with the results of said queries (if
+there are any) being emailed to the user. Events are created by
+clicking on the "Add new event" button.
+
+Once a new event is created, the first thing to set is the "Email
+subject line". The contents of this field will be used in the subject
+line of every email generated by this event. In addition to setting a
+subject, space is provided to enter some descriptive text that will be
+included at the top of each message (to help you in understanding why
+you received the email in the first place).
+
+The next step is to specify when the Event is to be run (the Schedule)
+and what searches are to be performed (the Searches).
+
+.. _whining-schedule:
+
+Whining Schedule
+================
+
+Each whining event is associated with zero or more schedules. A
+schedule is used to specify when the search (specified below) is to be
+run. A new event starts out with no schedules (which means it will
+never run, as it is not scheduled to run). To add a schedule, press
+the "Add a new schedule" button.
+
+Each schedule includes an interval, which you use to tell Bugzilla
+when the event should be run. An event can be run on certain days of
+the week, certain days of the month, during weekdays (defined as
+Monday through Friday), or every day.
+
+.. warning:: Be careful if you set your event to run on the 29th, 30th, or 31st of
+ the month, as your event may not run exactly when expected. If you
+ want your event to run on the last day of the month, select "Last day
+ of the month" as the interval.
+
+Once you have specified the day(s) on which the event is to be run, you
+should now specify the time at which the event is to be run. You can
+have the event run at a certain hour on the specified day(s), or
+every hour, half-hour, or quarter-hour on the specified day(s).
+
+If a single schedule does not execute an event as many times as you
+would want, you can create another schedule for the same event. For
+example, if you want to run an event on days whose numbers are
+divisible by seven, you would need to add four schedules to the event,
+setting the schedules to run on the 7th, 14th, 21st, and 28th (one day
+per schedule) at whatever time (or times) you choose.
+
+.. note:: If you are a member of the bz_canusewhineatothers group, then you
+ will be presented with another option: "Mail to". Using this you
+ can control who will receive the emails generated by this event. You
+ can choose to send the emails to a single user (identified by email
+ address) or a single group (identified by group name). To send to
+ multiple users or groups, create a new schedule for each additional
+ user/group.
+
+.. _whining-query:
+
+Whining Searches
+================
+
+Each whining event is associated with zero or more searches. A search
+is any saved search to be run as part of the specified schedule (see
+above). You start out without any searches associated with the event
+(which means that the event will not run, as there will never be any
+results to return). To add a search, press the "Add a search" button.
+
+The first field to examine in your newly added search is the Sort field.
+Searches are run, and results included, in the order specified by the
+Sort field. Searches with smaller Sort values will run before searches
+with bigger Sort values.
+
+The next field to examine is the Search field. This is where you
+choose the actual search that is to be run. Instead of defining search
+parameters here, you are asked to choose from the list of saved
+searches (the same list that appears at the bottom of every Bugzilla
+page). You are only allowed to choose from searches that you have
+saved yourself (the default saved search, "My Bugs", is not a valid
+choice). If you do not have any saved searches, you can take this
+opportunity to create one (see :ref:`list`).
+
+.. note:: When running searches, the whining system acts as if you are the user
+ executing the search. This means that the whining system will ignore
+ bugs that match your search, but that you cannot access.
+
+Once you have chosen the saved search to be executed, give the search a
+descriptive title. This title will appear in the email, above the
+results of the search. If you choose "One message per bug", the search
+title will appear at the top of each email that contains a bug matching
+your search.
+
+Finally, decide if the results of the search should be sent in a single
+email, or if each bug should appear in its own email.
+
+.. warning:: Think carefully before checking the "One message per bug" box. If
+ you create a search that matches thousands of bugs, you will receive
+ thousands of emails!
+
+Saving Your Changes
+===================
+
+Once you have defined at least one schedule, and created at least one
+search, go ahead and "Update/Commit". This will save your Event and make
+it available for immediate execution.
+
+.. note:: If you ever feel like deleting your event, you may do so using the
+ "Remove Event" button in the upper-right corner of each Event. You
+ can also modify an existing event, so long as you "Update/Commit"
+ after completing your modifications.
+
+