The status and resolution fields define and track the life cycle of a bug.

STATUS

RESOLUTION
The status field indicates the general health of a bug. Only certain status transitions are allowed. The resolution field indicates what happened to this bug.
UNCONFIRMED
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.
NEW
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 RESOLVED.
ASSIGNED
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.
REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For example, a bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.
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 resolutions.
RESOLVED
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.
VERIFIED
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 CLOSED.
CLOSED
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.
FIXED
A fix for this bug is checked into the tree and tested.
INVALID
The problem described is not a bug.
WONTFIX
The problem described is a bug which will never be fixed.
DUPLICATE
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.
WORKSFORME
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.
MOVED
The problem was specific to a related product whose bugs are tracked in another bug database. The bug has been moved to that database.

Severity

This field describes the impact of a bug
Blocker Blocks development and/or testing work
Critical The product is rendered non-operational for a period of time, resulting from a severe product problem. This would include problems that seriously impact the customer¡¯s ability to continue with use of the product. The impact of Severity 1 issues includes loss of service, or unrecoverable data loss
Examples of Severity 1 problems:
--System restart or reboot that results in a significant loss of service to the customer.
--Problem prevents successful product installation or upgrade.
--Loss of service/major disruption in a critical system resource.
--Problem causes significant loss or corruption of customer data.
--Outage or server degradation in a major product area..
Major (High) The product operation has significant limitations negatively impacting the customer¡¯s business. There is degradation in a commonly used feature or a problem resulting in a less serious but frequent degradation that would require frequent intervention or significant operational change.
Examples of Severity 2 problems:
--Major committed feature does not work as specified
--Repeated disruption of customer service for short periods of time
--Problem is frequent, persistent and affects many users
--Product does not meet advertised performance or capacity
--Problem blocks the ability to service the product
Normal (Medium) The product operation is impaired or there are limitations. The problem causes inconvenience to a customer or Services but does not cause a critical outage. The problem is not considered service affecting and can be temporarily circumvented or avoided. All product problems escalated by a customer are at least a severity 3.
Examples of Severity 3 problems:
--Moderate problems in a feature, but a satisfactory workaround exists
--Problem interferes with the serviceability of the product in a timely manner
--A limited problem that does not cause loss of service or loss of critical customer data
--Factual errors or errors in customer facing documentation or on-line help
--Problem causes users moderate confusion or irritation.
Minor (Low) The problem may cause an inconvenience or annoyance to customers or Services.
Examples of Severity 4 problems:
--Minor annoyances including appearance layout/formatting
--Minor impacts to efficiency of operations
--Cosmetic and spelling/grammar errors in customer facing documentation or on line help
Trivial Cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

Priority

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 P5 (least important.)
In general, Critical bugs should have P1 Priority, Major and Normal bugs should have P2 Priority, Minor bugs should have P3 Priority.

Platform

This is the hardware platform against which the bug was reported. Legal platforms include: Note: When searching, selecting the option "All" does not select bugs assigned against any platform. It merely selects bugs that are marked as occurring on all platforms, i.e. are designated "All".

Operating System

This is the operating system against which the bug was reported. Legal operating systems include: Sometimes the operating system implies the platform, but not always. For example, Linux can run on PC and Macintosh and others.

Assigned To

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, and REOPENED. When searching for bugs that have been resolved or verified, remember to set the status field appropriately.