This page describes the various fields that you see on an issue.



The Status field indicates the current state of a issue. Only certain status transitions are allowed. The Resolution field indicates what happened to this issue.
Open Issues
This issue has recently been added to the database. Nobody has confirmed that this issue is valid. Users who have the "canconfirm" permission set may confirm this issue, changing its state to CONFIRMED. Or, it may be directly resolved and marked RESOLVED.
This issue is valid and has recently been filed. Issues in this state become IN_PROGRESS when somebody is working on them, or become resolved and marked RESOLVED.
This issue is not yet resolved, but is assigned to the proper person who is working on the issue. From here, issues can be given to another person and become CONFIRMED, or resolved and become RESOLVED.
No resolution yet. All issues which are in one of these "open" states have no resolution set.
Closed Issues
A resolution has been performed, and it is awaiting verification by QA. From here issues are either reopened and given some open status, or are verified by QA and marked VERIFIED.
QA has looked at the issue and the resolution and agrees that the appropriate resolution has been taken. This is the final status for issues.
A fix for this issue is checked into the tree and tested.
The problem described is not an issue.
The problem described is an issue which will never be fixed.
The problem is a duplicate of an existing issue. When an issue is marked as a DUPLICATE, you will see which issue it is a duplicate of, next to the resolution.
All attempts at reproducing this issue were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the issue can be reopened.

Other Fields

A short, unique name assigned to an issue in order to assist with looking it up and referring to it in other places in Bugzilla.
The developer in charge of progressing the issue.
Assignee Real Name
A custom Unknown Type field in this installation of Bugzilla.
This issue must be resolved before the issues listed in this field can be resolved.
Users who may not have a direct role to play on this issue, but who are interested in its progress.
When this issue was last updated.
Issues are categorised into Classifications, Products and Components. classifications is the top-level categorisation.
Issues have comments added to them by Bugzilla users. You can search for some text in those comments.
Comment Tag
A custom Unknown Type field in this installation of Bugzilla.
Components are second-level categories; each belongs to a particular Product. Select a Product to narrow down this list.
This is a field available in searches that does a Google-like 'full-text' search on the Summary and Comment fields.
Creation date
When the issue was filed.
The date that this issue must be resolved by, entered in YYYY-MM-DD format.
Depends on
The issues listed here must be resolved before this issue can be resolved.
Developer Difficulty
This field indicates how difficult it is for a developer to fix this issue. Of course every developer is different in her/his skills. So, please see this field as an approximated value.
The hardware platform the issue was observed on. Note: When searching, selecting the option "All" only finds issues whose value for this field is literally the word "All".
The importance of an issue is described as the combination of its Priority and Severity.
Issue ID
The numeric id of an issue, unique within this entire installation of Bugzilla.
Issue Type
A custom Drop Down field in this installation of Bugzilla.
You can add keywords from a defined list to issues, in order to easily identify and group them.
Last Visit
A custom Date/Time field in this installation of Bugzilla.
Latest Confirmation in
Old bugs have to be checked regularly as they are often fixed indirectly and can no longer be reproduced in newer releases. The "latest confirmation field" should be updated and a comment be added when the bug can be also confirmed in a newer release.
The operating systems the issue can be observed on. Note: When searching, selecting the option "All" only finds issues whose value for this field is literally the word "All".
Personal Tags
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 notification to other users. Use them to tag and keep track of issues.
Engineers prioritize their issues using this field.
Issues are categorised into Products and Components.
QA Contact
The person responsible for confirming this issue if it is unconfirmed, and for verifying the fix once the issue has been resolved.
QA Contact Real Name
A custom Unknown Type field in this installation of Bugzilla.
The person who filed this issue.
Reporter Real Name
A custom Unknown Type field in this installation of Bugzilla.
See Also
This allows you to refer to issues in other installations. You can enter a URL to an issue in the 'Add Issue URLs' field to note that that issue is related to this one. You can enter multiple URLs at once by separating them with whitespace.

You should normally use this field to refer to issues in other installations. For issues in this installation, it is better to use the Depends on and Blocks fields.

How severe the issue is, or whether it's an enhancement.
The issue summary is a short sentence which succinctly describes what the issue is about.
Target Milestone
The Target Milestone field is used to define when the engineer the issue is assigned to expects to fix it.
Issues can have a URL associated with them - for example, a pointer to a web site where the problem is seen.
The oldest version of the software the issue can be found in.
Some issues can be voted for, and you can limit your search to issues with more than a certain number of votes.