Issue Manager reason codes are optional, customizable keywords that describe why an issue has changed its state when a given action is taken.
A number of actions can cause an issue to move to the same state. For example, an issue can be closed for a variety of reasons: it's not reproducible, it's a duplicate, it's not a bug. Without the extra information supplied by the reason code, users will have an incomplete picture of an issue's life cycle.
Reason codes can also help you minimize the number of states in your workflow. For example, instead of defining several terminal states- Not a Bug, Not Reproducible, Duplicate, it is sufficient to have one terminal state called Closed with a variety of reason codes that indicate why an action closed an issue with, for example, Closed/Not a Bug.
The user sees reason codes on the Issue Details page and the action dialogs. For example, Judy, a technical writer, receives a documentation issue in her inbox. Reading the description, she recalls that the issue has already been reported. She marks the issue as a duplicate. When the Mark as Duplicate dialog box opens, she can see that the issue has moved from Open-Doc to Closed/Duplicate. Closed is the new state and Duplicate is the reason code.
When certain actions are taken, Issue Manager assigns a reason code to the action and passes it on to the new state. Subsequent actions might clear the reason code or simply retain the reason code. In general, once you set a reason code, it travels with the issue until it reaches the terminal state in the workflow.
Consider the case of a developer who fixes a bug and then takes the Fixed action to claim that the bug has been fixed. This action moves the bug from Dev-Ready to QA-Ready, and sets the reason code to Fixed. The QA engineer who is verifying the developer's claim accepts the bug fix by taking the Verified action. This action retains the Fixed reason code and moves the bug along to the Closed state.
However, you might want to clear the reason code, for example, when an issue returns to an earlier state in the workflow, instead of progressing toward a terminal state. Say that a QA engineer disputes a developer's claim and takes the Reject action, which sends the issue back to the Dev-Ready state. The Fixed reason code no longer makes sense, so you might want to clear the reason code for the Reject action.
Whether reason codes are assigned, cleared, or retained is determined by the setting in the New Action for State dialog, which is described in Reason code. Click and click Add Action to view the New Action for State dialog box