The status and resolution fields define and track the life
cycle of a bug.
|The status field indicates the general health of a bug. Only certain status transitions are allowed.
||The resolution field indicates what happened to this
This bug has recently been added to the database.
Nobody has validated that this bug is true. Users
who have the "canconfirm" permission set may confirm
this bug, changing its state to NEW. Or, it may be
directly resolved and marked RESOLVED.
This bug has recently been added to the assignee's
list of bugs and must be processed. Bugs in
this state may be accepted, and become ASSIGNED, passed
on to someone else, and remain NEW, or resolved and marked
This bug is not yet resolved, but is assigned to the
proper person. From here bugs can be given to another
person and become NEW, or
resolved and become RESOLVED.
This bug was once resolved, but the resolution was
deemed incorrect. For example, a WORKSFORME bug is
REOPENED when more information shows up and
the bug is now reproducible. From here bugs are
either marked ASSIGNED or
No resolution yet. All bugs which are in one of
these "open" states have the resolution set to blank. All
other bugs will be marked with one of the following
A resolution has been taken, and it is awaiting verification by
QA. From here bugs are either re-opened and become
REOPENED, are marked
VERIFIED, or are closed for
good and marked CLOSED.
QA has looked at the bug and the resolution and
agrees that the appropriate resolution has been taken. Bugs remain
in this state until the product they were reported
against actually ships, at which point they become
The bug is considered dead, the resolution is correct.
Any zombie bugs who choose to walk the earth again must
do so by becoming REOPENED.
A fix for this bug is checked into the tree and
The problem described is not a bug.
The problem described is a bug which will never be
The problem is a duplicate of an existing bug.
Marking a bug duplicate requires the bug#
of the duplicating bug and will at least put
that bug number in the description field.
All attempts at reproducing this bug were futile,
and reading the code produces no clues as to why the described
behavior would occur. If more information appears later,
the bug can be reopened.
The problem was specific to a related product
whose bugs are tracked in
another bug database.
The bug has been moved to that database.
The importance of a bug is described as the combination of
as described below.
This field describes the importance and order in which a bug
should be fixed. This field is utilized by the
programmers/engineers to prioritize their work to be done. The
available priorities range from P1
(most important) to
This field describes the impact of a bug.
||Blocks development and/or testing work
||crashes, loss of data, severe memory leak
||major loss of function
||regular issue, some loss of functionality under specific circumstances
||minor loss of function, or other problem where easy
workaround is present
||cosmetic problem like misspelled words or misaligned
||Request for enhancement
This is the hardware platform against which the bug was
reported. Legal platforms include:
- All (happens on all platforms; cross-platform bug)
When searching, selecting the option "All" does not
assigned against any platform. It merely selects bugs that are
marked as occurring on all platforms, i.e. are designated "All".
This is the operating system against which the bug was
reported. Legal operating systems include:
- All (happens on all operating systems; cross-platformbug)
- Mac OS
Sometimes the operating system implies the platform, but not
always. For example, Linux can run on PC and Macintosh and
This is the person in charge of resolving the bug. Every time
this field changes, the status changes to NEW to make it
easy to see which new bugs have appeared on a person's list.
The default status for queries is set to NEW,
ASSIGNED and REOPENED.
When searching for bugs that have been resolved or
verified, remember to set the status field appropriately.