[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.
UNCONFIRMED issue which gets enough votes becomes automatically confirmed, and enters the NEW state.That's why it is worthwhile to search the issue database for duplicates of your issue to vote on them before submitting your own issue. This helps to prevent issue duplication in the database.
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.