You can allow individual users or entire groups to override the normal routing for verifying issues in your organization.
For example, a user might want to verify that the reported issues have been fixed.
To permit such an override, assign the
Issue verification preferences privilege to the user or group. With this security privilege, users can then choose one of the following three strategies
from
:
- Strategy
- Description
- Always use normal routing
- Normal routing for verification. The issue will be routed to the appropriate QA inbox.
- Always verify your own issue
- Have
Issue Manager route issues that users submit to their own inboxes for verification, rather than to the typical QA inbox.
- Prompt for each new issue
- Have
Issue Manager give users the option to override normal routing each time an issue is reported.
Reassignment overrides automatic routing
Reassigning an issue is a method of manual routing that overrides the automatic routing mechanism. A user can explicitly take
the Reassign action to route an issue to the inbox of another user, typically a user in the same group. For example, developer
Bill, who is going on vacation, might reassign a Dev-Ready bug to his developer colleague Dan. The bug remains in the Dev-Ready
state, but it has been reassigned.
When an issue that has been reassigned returns to a previous state in the workflow, for example if Dan were to reject a bug
fix,
Issue Manager remembers the reassignment and later returns the issue to the inbox to which the issue was manually routed, which in this
case is Dan's inbox, rather than to the inbox to which it was originally routed, which in this case is Bill's inbox.
Example
To appreciate how efficiently reassignment works, consider an example in which a bug is reassigned twice - once in the Dev-Ready
state and once in the QA-Ready state, and the QA engineer rejects a bug fix, sending the bug back to an earlier state in the
workflow.
- A new bug enters the workflow in the
Dev-Ready state. The routing rules automatically send the bug to the inbox of developer Bill.
- Bill reassigns the bug to the inbox of developer Dan.
- Dan claims that the bug has been fixed, which sends the bug to the
QA-Ready state.
- The routing rules automatically route the bug to the inbox of QA engineer Mike for verification.
- Mike reassigns the bug to the inbox of his colleague Sarah.
- Sarah rejects the fix, which sends the bug back to Dev-Ready.
- Issue Manager routes the Dev-Ready bug back to the inbox of Dan, because he was the last developer to act on the bug in that state.
- Dan fixes the bug again, sending the bug back to QA-Ready.
- Issue Manager routes the QA-Ready bug back to Sarah's inbox, because she was the last QA engineer to act on the bug in that state.
Without enhanced routing, the issue in the Dev-Ready state (step 7) would be routed to Bill's inbox, who would then once again
reassign the issue to Dan. Similarly, the issue in the QA-Ready state (step 9) would be routed to Mike's inbox, who would
then once again reassign the issue to Sarah.