![microsoft team foundation server 2010 power tools microsoft team foundation server 2010 power tools](https://docs.microsoft.com/en-us/visualstudio/releasenotes/media/tfs2018_85-2.png)
This brings up the Workflow Transition dialog: To set the reason why the workflow goes from “ Awaiting approval” to “ Accepted” we double-click the transition object connecting them. We can click the downwards-pointing double arrow to modify the transition object:Įach transition must be given a reason which explains why the workflow progressed from one state to the next. When two state objects have been connected by a transition link we see a new blue transition object. We repeat this for the “ Not accepted” state: To connect the workflow states we click the Transition Link tool in the toolbox and then we click the “ Awaiting approval” state followed by the “ Accepted” state. We repeat this process for the “ Not accepted” state:
![microsoft team foundation server 2010 power tools microsoft team foundation server 2010 power tools](http://1.bp.blogspot.com/-HypnOqOhDnU/Uh8Ob01k6vI/AAAAAAAAAdM/mEgz0FF1GOI/s400/Untitled.png)
We double-click the new State object and name it “ Accepted”. We do this by adding a new State object to the workflow: In order to allow a product manager, or other similar role, to approve the resolution of a bug we need to add two additional states: “ Accepted” and the less popular “ Not accepted”. When the bug is done we consider it to be in need of approval, so we change the name of the “ Done” state to “ Awaiting approval”: We also change the name of the “ Committed” state to “ In progress”: We do this by pulling up the standard Visual Studio toolbox which, when a workflow is being displayed, gives a few basic – but useful – artifacts to customize the workflow:įirst off we want to rename the somewhat confusing “ Approved” state to “ Verified” (indicating that the reported bug is indeed a bug), so we simply double-click the red state object and change its name to “Verified”: We want to rename some of these different states, and also add a few new ones. The original workflow for the Bug item type in the Visual Studio Scrum 1.0 template takes bugs from New to Approved to Committed and finally to Done – unless they are Removed: We click the Workflow tab to edit the workflow associated with the Bug work item type: We could for example modify the workflow for the Bug work item type in order to add additional states to make it fit our work process: To modify a workflow you open up the work item associated with the workflow. …we’ll be able to see our new custom field in action: We’ll set a label for the control and select the field we created earlier: When we’re done we can switch to the Layout tab to add our field to the work item editor: …and then we set group restrictions (optional) and click the New button to add our options: We’ll select the SUGGESTEDVALUES option in the next dialog… We click the Rules tab and click the Add button: Next, let’s add a rule for specifying available value options for this field. Next, we give our new field a name, a reference name, and optionally a description: We click New on the Fields tab to add a custom field: So, if we want to modify the Task work item type for our website’s TFS project we’ll simply expand its node and select the Task work item type: This brings up a dialog with the available TFS projects. The Process Editor allows you to edit work item types, either globally or for a specific TFS project.įor example, we can modify the Task work item type to add a custom field by clicking Work Item Types and selecting Open WIT from Server:
#Microsoft team foundation server 2010 power tools install#
When you install TFS Power Tools you get an additional menu option called Process Editor under Tools in Visual Studio 2010: Microsoft Visual Studio Scrum 1.0 (process template).We use Team Foundation Server (TFS) 2010 to manage our projects including source control, product backlogs, tasks, and bug tracking.