[This document is aimed primarily at people who may have used IssueZilla before the UNCONFIRMED state was implemented. It might be helpful for newer users as well.]

New issues in some products will now show up in a new state, UNCONFIRMED. This means that nobody has confirmed that the issue is real. Very busy developers generally ignore UNCONFIRMED that have been assigned to them, until they have been confirmed in one way or another. (Developers with more time will hopefully glance over their UNCONFIRMED issues regularly.)

There are two basic ways that an issue can become confirmed (and thus enter the NEW) state.

• A user with the appropriate permissions (see below for more on permissions) decides that the issue is a valid one, and confirms it.

• The issue gathers a certain number of votes. Any valid IssueZilla user may vote for issues (each user gets a certain number of issues); any UNCONFIRMED issue which gets enough votes becomes automatically confirmed, and enters the NEW state.

Permissions and the UNCONFIRMED issue state

If you have the "Can confirm an issue" permission, then you will be able to change UNCONFIRMED issues to the NEW state.

If you not have the "Can confirm an issue" permission, you can still ACCEPT or RESOLVE all issues assigned to you. IssueZilla keeps track of this. If this issue gets REOPENED or reassigned to someone else, it reverts back to the UNCONFIRMED state. If such an issue has been confirmed, then reassigning changes its status to NEW or REOPENED.

If you have the "Can edit all aspects of any issue" permission, when you submit issues, these start out in the NEW state rather than the UNCONFIRMED state. You can override this feature, however, when you want to submit an issue as UNCONFIRMED.