You can allow individual users or entire groups to override your organization’s normal routing for verifying issues. For example, a user might want to verify that the issues they’ve reported have been fixed.
To permit such an override, assign the Issue verification preferences privilege to the user and or group (as explained in “Managing User Accounts” and “Customization privileges”. With this security privilege, users can then choose one of the following three strategies from the Preferences page (Configuration/Preferences). They can:
• 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 described in this chapter. 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 (Dan’s), rather than to the inbox to which it was originally routed (Bill’s).
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.
1 A new bug enters the workflow in the Dev-Ready state. The routing rules automatically send the bug to developer Bill’s inbox.
2 Bill reassigns the bug to developer Dan’s inbox.
3 Dan claims that the bug has been fixed, which sends the bug to the QA-Ready state.
4 The routing rules automatically route the bug to QA engineer Mike’s inbox for verification.
5 Mike reassigns the bug to the inbox of his colleague Sarah.
6 Sarah rejects the fix, which sends the bug back to Dev-Ready.
7 Issue Manager routes the Dev-Ready bug back to Dan’s inbox, because he was the last developer to act on the bug in that state.
8 Dan fixes the bug again, sending the bug back to QA-Ready.
9 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.