The state of an issue is the issue’s current condition. A number of states are provided in Issue Manager’s default workflow, which is described in “Customizing Workflow”. The state owner is the role in your organization that is responsible for acting on an issue in a given state.
Some examples of issue states and owners from the default issue workflow are:
• Unreviewed: Someone needs to determine whether or not this issue is truly a bug or documentation error. Usually, this role is owned by a QA engineer.
• Dev-Ready: Code is ready to be addressed. This role is typically owned by a developer.
• QA-Ready: Someone needs to verify that the bug has actually been fixed. This role is usually owned by a QA engineer.
Different issues of the same type can enter the workflow in different states, depending on who submits them. The routing is affected accordingly. For example, an issue submitted by a developer enters the workflow in the Dev-Ready state, and is therefore routed to a developer’s inbox. An issue submitted by a corporate user enters the workflow in the Unreviewed state, and is therefore routed to a QA engineer’s inbox. The so-called initial issue state is assigned via group settings (“Setting Up Groups”).
An issue moves from one state to the next in the workflow when a user takes action on that issue. For example, when a QA engineer confirms that a reported, unreviewed issue is indeed a bug, the issue moves from the Unreviewed state to the Dev-Ready state. The main goal of using routing logic here is to make sure that once the issue is judged to be a bug by the QA engineer, it moves from his or her inbox to the appropriate developer’s inbox—without need for manual intervention.