Austin Agile DevOps

DevOps in the Cloud
posts - 70 , comments - 7 , trackbacks - 0

Updating an incorrect reason code after a state transition

When using TFS work items you may find that when you transition from one state to another that you selected the wrong reason code, or you found out shortly afterwards that the reason code you selected is incorrect.

Well, you may be surprised to find that reason codes (System.Reason) cannot be updated within the same state.

After some looking into, I came to understand the intent of reason code is to document the "reason" the state changed. As opposed to indicate within state changes. However, it was also clear that no out-of-the-box provision is made for correcting the reason code when the wrong one was used. I did find two different approaches that used a custom field:

One replaces System.Reason with a custom field. Another uses a custom field that gets populated from System.Reason and can then be updated.

I appreciate the approach of using a custom field, as shown in the article. However, wanting to minimize custom code, I took the following approach:

Using the Process Editor:

  • I simply created an "Update [state] Reason Code" state
  • The transition reason to this state is "Current reason code is incorrect."
  • The transition back provides the list of reason codes to chose from

This was easy and leverages the existing fields and functionality. It also provides a nice, concise history and allows the application of permissions to limit who can do this. I found I didn't need to use this on most of my states because many of them can already go back to the immediately prior state and so it amounts to the same thing. Using it on the initial state (Submitted) and Close will be very helpful.

Print | posted on Tuesday, May 15, 2012 8:32 AM | Filed Under [ Agile SCM Talk Blog ]


No comments posted yet.
Post A Comment

Powered by: