<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>2.3. Understanding a Bug — Bugzilla 5.0.4 documentation</title>
<link rel="stylesheet" href="../_static/bugzilla.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '5.0.4',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true,
SOURCELINK_SUFFIX: '.txt'
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="shortcut icon" href="../_static/favicon.ico"/>
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="2.4. Editing a Bug" href="editing.html" />
<link rel="prev" title="2.2. Filing a Bug" href="filing.html" />
</head>
<body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="editing.html" title="2.4. Editing a Bug"
accesskey="N">next</a></li>
<li class="right" >
<a href="filing.html" title="2.2. Filing a Bug"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">Bugzilla 5.0.4 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">2. User Guide</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="understanding-a-bug">
<span id="understanding"></span><h1>2.3. Understanding a Bug<a class="headerlink" href="#understanding-a-bug" title="Permalink to this headline">¶</a></h1>
<p>The core of Bugzilla is the screen which displays a particular
bug. 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.</p>
<dl class="docutils">
<dt><em>Summary:</em></dt>
<dd>A one-sentence summary of the problem, displayed in the header next to
the bug number.</dd>
<dt><em>Status (and Resolution):</em></dt>
<dd>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.</dd>
<dt><em>Alias:</em></dt>
<dd>A unique short text name for the bug, which can be used instead of the
bug number.</dd>
<dt><em>Product and Component</em>:</dt>
<dd>Bugs are divided up by Product and Component, with a Product
having one or more Components in it.</dd>
<dt><em>Version:</em></dt>
<dd>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.</dd>
<dt><em>Hardware (Platform and OS):</em></dt>
<dd>These indicate the computing environment where the bug was
found.</dd>
<dt><em>Importance (Priority and Severity):</em></dt>
<dd><p class="first">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.</p>
<p class="last">The Severity field 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.</p>
</dd>
<dt><em>*Target Milestone:</em></dt>
<dd>A future version by which the bug is to
be fixed. e.g. The Bugzilla Project's milestones for future
Bugzilla versions are 4.4, 5.0, 6.0, etc. Milestones are not
restricted to numbers, though—you can use any text strings, such
as dates.</dd>
<dt><em>Assigned To:</em></dt>
<dd>The person responsible for fixing the bug.</dd>
<dt><em>*QA Contact:</em></dt>
<dd>The person responsible for quality assurance on this bug.</dd>
<dt><em>URL:</em></dt>
<dd>A URL associated with the bug, if any.</dd>
<dt><em>*Whiteboard:</em></dt>
<dd>A free-form text area for adding short notes and tags to a bug.</dd>
<dt><em>Keywords:</em></dt>
<dd>The administrator can define keywords which you can use to tag and
categorise bugs—e.g. <code class="docutils literal"><span class="pre">crash</span></code> or <code class="docutils literal"><span class="pre">regression</span></code>.</dd>
<dt><em>Personal Tags:</em></dt>
<dd>Unlike Keywords which are global and visible by all users, Personal Tags
are personal and can only be viewed and edited by their author. Editing
them won't send any notifications to other users. Use them to tag and keep
track of sets of bugs that you personally care about, using your own
classification system.</dd>
<dt><em>Dependencies (Depends On and Blocks):</em></dt>
<dd><p class="first">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.</p>
<p class="last">Clicking the <span class="guilabel">Dependency tree</span> 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 collapse/expand dependencies for
each non-terminal bug on the tree view, using the [-]/[+] buttons that
appear before the summary.</p>
</dd>
<dt><em>Reported:</em></dt>
<dd>The person who filed the bug, and the date and time they did it.</dd>
<dt><em>Modified:</em></dt>
<dd>The date and time the bug was last changed.</dd>
<dt><em>CC List:</em></dt>
<dd>A list of people who get mail when the bug changes, in addition to the
Reporter, Assignee and QA Contact (if enabled).</dd>
<dt><em>Ignore Bug Mail:</em></dt>
<dd>Set this if you want never to get bugmail from this bug again. See also
<a class="reference internal" href="preferences.html#emailpreferences"><span class="std std-ref">Email Preferences</span></a>.</dd>
<dt><em>*See Also:</em></dt>
<dd>Bugs, in this Bugzilla, other Bugzillas, or other bug trackers, that are
related to this one.</dd>
<dt><em>Flags:</em></dt>
<dd>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. See <a class="reference internal" href="#flags"><span class="std std-ref">Flags</span></a>.</dd>
<dt><em>*Time Tracking:</em></dt>
<dd><p class="first">This form can be used for time tracking.
To use this feature, you have to be a member of the group
specified by the <span class="param">timetrackinggroup</span> parameter. See
<a class="reference internal" href="editing.html#time-tracking"><span class="std std-ref">Time Tracking</span></a> for more information.</p>
<dl class="last docutils">
<dt>Orig. Est.:</dt>
<dd>This field shows the original estimated time.</dd>
<dt>Current Est.:</dt>
<dd>This field shows the current estimated time.
This number is calculated from <code class="docutils literal"><span class="pre">Hours</span> <span class="pre">Worked</span></code>
and <code class="docutils literal"><span class="pre">Hours</span> <span class="pre">Left</span></code>.</dd>
<dt>Hours Worked:</dt>
<dd>This field shows the number of hours worked.</dd>
<dt>Hours Left:</dt>
<dd>This field shows the <code class="docutils literal"><span class="pre">Current</span> <span class="pre">Est.</span></code> -
<code class="docutils literal"><span class="pre">Hours</span> <span class="pre">Worked</span></code>.
This value + <code class="docutils literal"><span class="pre">Hours</span> <span class="pre">Worked</span></code> will become the
new Current Est.</dd>
<dt>%Complete:</dt>
<dd>This field shows what percentage of the task is complete.</dd>
<dt>Gain:</dt>
<dd>This field shows the number of hours that the bug is ahead of the
<code class="docutils literal"><span class="pre">Orig.</span> <span class="pre">Est.</span></code>.</dd>
<dt>Deadline:</dt>
<dd>This field shows the deadline for this bug.</dd>
</dl>
</dd>
<dt><em>Attachments:</em></dt>
<dd>You can attach files (e.g. test cases or patches) to bugs. If there
are any attachments, they are listed in this section. See
<a class="reference internal" href="editing.html#attachments"><span class="std std-ref">Attachments</span></a> for more information.</dd>
<dt><em>Additional Comments:</em></dt>
<dd>You can add your two cents to the bug discussion here, if you have
something worthwhile to say.</dd>
</dl>
<div class="section" id="flags">
<span id="id1"></span><h2>2.3.1. Flags<a class="headerlink" href="#flags" title="Permalink to this headline">¶</a></h2>
<p>Flags are a way to attach a specific status to a bug or attachment,
either <code class="docutils literal"><span class="pre">+</span></code> or <code class="docutils literal"><span class="pre">-</span></code>. The meaning of these symbols depends on the name of
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 <code class="docutils literal"><span class="pre">?</span></code> as a
request to another user that they look at the bug/attachment and set
the flag to its correct status.</p>
<p>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 <code class="docutils literal"><span class="pre">+</span></code>, it appears
as <span class="guilabel">Jack: review [ + ]</span>.</p>
<p>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 <span class="guilabel">Jack: review [ ? ] (Jill)</span>.</p>
<p>You can browse through open requests made of you and by you by selecting
<span class="guilabel">My Requests</span> 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.</p>
<div class="section" id="a-simple-example">
<span id="flags-simpleexample"></span><h3>2.3.1.1. A Simple Example<a class="headerlink" href="#a-simple-example" title="Permalink to this headline">¶</a></h3>
<p>A developer might want to ask their manager,
"Should we fix this bug before we release version 2.0?"
They might want to do this for a <em>lot</em> of bugs,
so they decide to streamline the process. So:</p>
<ol class="arabic simple">
<li>The Bugzilla administrator creates a flag type called blocking2.0 for bugs
in your product. It shows up on the <span class="guilabel">Show Bug</span> screen as the text
<span class="guilabel">blocking2.0</span> with a drop-down box next to it. The drop-down box
contains four values: an empty space, <code class="docutils literal"><span class="pre">?</span></code>, <code class="docutils literal"><span class="pre">-</span></code>, and <code class="docutils literal"><span class="pre">+</span></code>.</li>
<li>The developer sets the flag to <code class="docutils literal"><span class="pre">?</span></code>.</li>
<li>The manager sees the <span class="guilabel">blocking2.0</span>
flag with a <code class="docutils literal"><span class="pre">?</span></code> value.</li>
<li>If the manager thinks the feature should go into the product
before version 2.0 can be released, they set the flag to
<code class="docutils literal"><span class="pre">+</span></code>. Otherwise, they set it to <code class="docutils literal"><span class="pre">-</span></code>.</li>
<li>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.</li>
</ol>
</div>
<div class="section" id="about-flags">
<span id="flags-about"></span><h3>2.3.1.2. About Flags<a class="headerlink" href="#about-flags" title="Permalink to this headline">¶</a></h3>
<p>Flags can have four values:</p>
<dl class="docutils">
<dt><code class="docutils literal"><span class="pre">?</span></code></dt>
<dd>A user is requesting that a status be set. (Think of it as 'A question is being asked'.)</dd>
<dt><code class="docutils literal"><span class="pre">-</span></code></dt>
<dd>The status has been set negatively. (The question has been answered <code class="docutils literal"><span class="pre">no</span></code>.)</dd>
<dt><code class="docutils literal"><span class="pre">+</span></code></dt>
<dd>The status has been set positively.
(The question has been answered <code class="docutils literal"><span class="pre">yes</span></code>.)</dd>
<dt><code class="docutils literal"><span class="pre">_</span></code></dt>
<dd><code class="docutils literal"><span class="pre">unset</span></code> actually shows up as a blank space. This just means that nobody
has expressed an opinion (or asked someone else to express an opinion)
about the matter covered by this flag.</dd>
</dl>
</div>
<div class="section" id="flag-requests">
<span id="flag-askto"></span><h3>2.3.1.3. Flag Requests<a class="headerlink" href="#flag-requests" title="Permalink to this headline">¶</a></h3>
<p>If a flag has been defined as <span class="guilabel">requestable</span>, and a user has enough
privileges to request it (see below), the user can set the flag's status to
<code class="docutils literal"><span class="pre">?</span></code>. This status indicates that someone (a.k.a. "the requester") is asking
someone else to set the flag to either <code class="docutils literal"><span class="pre">+</span></code> or <code class="docutils literal"><span class="pre">-</span></code>.</p>
<p>If a flag has been defined as <span class="guilabel">specifically requestable</span>,
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.</p>
<p>If a flag has <em>not</em> been defined as <span class="guilabel">specifically requestable</span>,
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.</p>
</div>
<div class="section" id="attachment-flags">
<span id="flag-type-attachment"></span><span id="flag-types"></span><h3>2.3.1.4. Attachment Flags<a class="headerlink" href="#attachment-flags" title="Permalink to this headline">¶</a></h3>
<p>There are two types of flags: bug flags and attachment flags.</p>
<p>Attachment flags are used to ask a question about a specific
attachment on a bug.</p>
<p>Many Bugzilla installations use this to
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
<span class="guilabel">review</span> to
<span class="guilabel">review? reviewer@example.com</span>.
reviewer@example.com is then notified by email that
they have to check out that attachment and approve it or deny it.</p>
<p>For a Bugzilla user, attachment flags show up in three places:</p>
<ol class="arabic simple">
<li>On the list of attachments in the <span class="guilabel">Show Bug</span>
screen, you can see the current state of any flags that
have been set to <code class="docutils literal"><span class="pre">?</span></code>, <code class="docutils literal"><span class="pre">+</span></code>, or <code class="docutils literal"><span class="pre">-</span></code>. You can see who asked about
the flag (the requester), and who is being asked (the
requestee).</li>
<li>When you edit an attachment, you can
see any settable flag, along with any flags that have
already been set. The <span class="guilabel">Edit Attachment</span>
screen is where you set flags to <code class="docutils literal"><span class="pre">?</span></code>, <code class="docutils literal"><span class="pre">-</span></code>, <code class="docutils literal"><span class="pre">+</span></code>, or unset them.</li>
<li>Requests are listed in the <span class="guilabel">Request Queue</span>, which
is accessible from the <span class="guilabel">My Requests</span> link (if you are
logged in) or <span class="guilabel">Requests</span> link (if you are logged out)
visible on all pages.</li>
</ol>
</div>
<div class="section" id="bug-flags">
<span id="flag-type-bug"></span><h3>2.3.1.5. Bug Flags<a class="headerlink" href="#bug-flags" title="Permalink to this headline">¶</a></h3>
<p>Bug flags are used to set a status on the bug itself. You can
see Bug Flags in the <span class="guilabel">Show Bug</span> and <span class="guilabel">Requests</span>
screens, as described above.</p>
<p>Only users with enough privileges (see below) may set flags on bugs.
This doesn't necessarily include the assignee, reporter, or users with the
<span class="group">editbugs</span> permission.</p>
<hr class="docutils" />
<p>This documentation undoubtedly has bugs; if you find some, please file
them <a class="reference external" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation">here</a>.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/bugzilla.png" alt="Logo"/>
</a></p>
<h3><a href="../index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">2.3. Understanding a Bug</a><ul>
<li><a class="reference internal" href="#flags">2.3.1. Flags</a><ul>
<li><a class="reference internal" href="#a-simple-example">2.3.1.1. A Simple Example</a></li>
<li><a class="reference internal" href="#about-flags">2.3.1.2. About Flags</a></li>
<li><a class="reference internal" href="#flag-requests">2.3.1.3. Flag Requests</a></li>
<li><a class="reference internal" href="#attachment-flags">2.3.1.4. Attachment Flags</a></li>
<li><a class="reference internal" href="#bug-flags">2.3.1.5. Bug Flags</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="filing.html"
title="previous chapter">2.2. Filing a Bug</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="editing.html"
title="next chapter">2.4. Editing a Bug</a></p>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="editing.html" title="2.4. Editing a Bug"
>next</a></li>
<li class="right" >
<a href="filing.html" title="2.2. Filing a Bug"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">Bugzilla 5.0.4 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" >2. User Guide</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.6.
</div>
</body>
</html>
