- Name
- Name of the next state in the workflow when this action is taken on an issue. For example, in the default workflow when an
Unreviewed issue is confirmed as a bug,
Issue Manager moves the issue to the next state,
Dev-Ready.
- Reason Code
- Optional keyword that describes why an issue has changed from the current state to the new state when this action is taken.
Select the appropriate option:
- No Change
- No Change indicates that the keyword is retained when the issue moves to the new state. It will appear in the Reason Code
field of the Issue Details page. For example, the following workflow shows that when a developer claims to have fixed a bug,
the bug moves to the QA-Ready state with a reason code of Fixed. If a QA engineer verifies the claim, then the bug moves to
the Closed state while retaining the Fixed reason code. Any user browsing issues can easily see the reason the bug has been
closed by looking at the reason code.
- Clear
- Indicates that the reason code for the current state will be removed when the issue moves to the new state. Clear is a reasonable
choice when an issue returns to a previous state in the workflow (for example, when a developer claims to have fixed a bug,
the bug moves to the
QA-Ready state with a reason code of Fixed). If, however, the “fix” is rejected, the issue is sent back to Development (Dev- Ready) and the
Fixed reason code is removed, since this claim is disputed. When you choose
Clear, the workflow displays
CLEAR in the
Reason Code field; however, the user sees an empty
Reason Code field on the
Issue Details page.
- Set to
-
Indicates that you can associate a reason code with this action. Enter a keyword of up to 20 characters. All capital letters
is recommended. Use
Set To to specify a reason code when an action moves an issue to a new state that requires a reason code. In general, you should
assign reason codes to all actions that developers take.
For example, in the default workflow the
Fixed action on the
Dev-Ready state sends the issue to the
QA-Ready state with a reason code of
Fixed. What this means in terms of human behavior is that when a developer claims that a bug has been fixed, he hands it off to
a QA engineer, who can now easily scan the
Issue Details page to see why the bug is in his or her inbox (the bug could also be there because the developer can’t fix it or the software
is working as designed).
If you do not use reason codes
Reason codes are optional keywords that can help to minimize the number of states in your workflow. For example, rather than
defining several closing states (Not a Bug,
Not Reproducible,
Not Repro, and
Duplicate) one terminal state is sufficient where reason codes help explain why the issue is in the
Closed state. If you decide not to use reason codes, you may need to have several terminal states. A state can be made a terminal
state by selecting the radio button called
No one (Terminal State), which appears as a choice in the
State Owner field of the
State Properties dialog.