Defining custom actions for state transitions

I heard this question few times: “I see the action named Microsoft.VSTS.Actions.Checkin to resolve work items in my tools, what other actions are available and how to use this feature to define my own”.

 

What is a “custom action” ? Suppose you are building a tool that will take shelveset from users and resolve workitems after running tests. Each work item type has its own set of states and rules and resolution means different for each work item type. So Resolve for task might be to move state to “Closed”, while for bug it is moving to “Resolved”. Custom actions defines this transition in work item type.

 

Here is syntax from msdn link (it also has documentation on this) : https://msdn2.microsoft.com/en-us/library/ms194975(VS.80).aspx

 

<TRANSITION from="Working" to="Ready To Build">

                <ACTIONS>

                                <ACTION value="Microsoft.VSTS.Actions.Checkin"/>

                                <ACTION value="ADatum.Actions.Complete"/>

                </ACTIONS>

</TRANSITION>

 

Let us take the example of resolving a bug again. We do it in the pending changes window (or checkin dialog) where work items can be associated with changesets before checking in, and upon checkin the work item will be resolved. Here is sample code piece that will do it:

 

                string nextState = wi.GetNextState("Microsoft.VSTS.Actions.Checkin");

                if (!String.IsNullOrEmpty(nextState))

                {

                                wi[CoreFieldReferenceNames.State] = nextState;

                                wi.History = "Work item resolved by tool xxx for reason yyy associated with changeset ccc";

                }

 

This basically calls GetNextState of a work item and passes the action. Next state is returned if the action is valid and the next state is possible with given rules. You can programmatically move the work item to next state.

 

This technique can be used in automated tools to work across various work item types in common way. This solves the problem for consistently handling state transitions and to check if a work item type can handle a specific action. We are thinking in the lines of extending this with features such as: ensuring a certain groups or categories of workitemtypes have specified set of fields, rules etc so that tools can handle groups of types consistently and automate wide range of functions.