TFS 2010 - Edit Work Item Type Definition using Team Foundation Power Tool
Posted by: Subodh Sohoni
in Category VSTS & TFS (Azure DevOps)
Abstract: We began a series of articles on Customize work item type definition in TFS 2010. In the first part of this series we had seen how to use a tool WitAdmin to export the work item type definition of Bug work item and then import it back in TFS after making a small modification in it, as Defect work item type definition. In this article, we will do a non-trivial modification in the Defect work item, using Team Foundation Power Tool.
We began a series of articles on Customize work item type definition in TFS 2010. In the first part of this series we had seen how to use a tool WitAdmin to export the work item type definition of Bug work item and then import it back in TFS after making a small modification in it, as Defect work item type definition. In this article, we will do a non-trivial modification in the Defect work item, using Team Foundation Power Tool.
As in previous article, we will do the walkthrough using the virtual machine created by Brian Keller. Whatever we did in the first walkthrough is a prerequisite for this one and if you have not done that walkthrough, then I suggest you to go back to first part of this series and complete that walkthrough before starting this one.
We will begin with using the Process Editor tool of the Team Foundation Power Tools to open the work item type definition of Defect work item.
Step 1: In the virtual machine, start Visual Studio 2010. If it is already open, then Refresh Team Explorer so that all the changes that you have done in the earlier exercise, will be rewritten in the cache of Visual Studio. This virtual machine has the installation of Team Foundation Power Tools that makes work item type definition customization task easy, non-tedious and less error prone.
Step 2: In the menu of the Visual Studio 2010, open Tools – Process Editor – Work Item Types – Open WIT from Server. We may open the WIT from a file like Bug.xml that we had created in the first exercise but it will have to be imported to TFS after editing to take effect.
Step 3: Connect to TFS and Default Collection
Step 4: Select Team Project “Tailspin Toys” and work item type Defect which was created in the earlier exercise.
Step 5: Team Foundation Power Tool has a GUI Editor for Work Item Type Definition editing. Defect work item type is opened in that.
You will be able to see the General Properties like Name, Description and three tabs for special properties that are Fields, layout and Workflow. We will add a new field in the Fields tab and add a control to show that field in the Layout tab. Finally we will add a state and transitions in the Workflow tab.
Step 6: We will add a field for “Organizational Department”. Click on the New icon on the Fields tab. It opens a field definition wizard that will create a field for us.
Step 7: In the text box for Name, provide the name: Division. Let the type remain same i.e. String but you may have a look at the other data types that can be assigned to the field. Reference name is the fully qualified name, by which the field will be known internally within the definition, as well as for programs using Team Foundation Object Model. Give the value SSGS.Division to Reference name. In the help text, enter the value: Stores the organizational division under which this Defect is being filed. Set the value Dimension to the Reportable attribute. The Definition should look similar to the one shown below:
Step 8: Now we will add a set of rules to follow (about this field) at the time when the work item of the type Defect will be saved. Click the tab for Rules.
Step 9: Click on the New icon to add a rule. The First rule that we will add is that whenever the work item of the type Defect will be saved, field Division has to be given some value. From the list box, select the rule REQUIRED. Do not add any other attribute to this rule and click OK twice to save this rule.
Another rule that we want to add is that user will be able to select value only from some allowed values. You will use the Global List Organizational Division that you had created in the earlier exercise. Click New icon to add another rule. Select the rule ALLOWEDVALUES.
When you click OK on this screen, you will see the editor for allowed values.
Click on the New icon to provide the values to the list of allowed values. It opens a list item editor. In the dropdown of that you will find the Global List that named “Organizational Divisions” that you had created in the earlier exercise.
Select that Global list and click OK. Click OK twice again to save the field definition.
Step 10: Click the layout tab and click Preview Form button on that.
You should add the Division field in the Classification group since it is one of the ways of classifying the defects. Close the preview form.
Step 11: In the layout tree, trace to the group named Classification. Right click on the Column under Classification group and select Add Control.
In the properties of new control, select the property Label and change the value to Division. Set the value of property Field Name to SSGS.Division from the dropdown.
Step 12: Click the Preview Form button again and preview of Classification group should look similar to the following:
Close the preview.
Step 13: Click the tab of the Workflow now. Existing workflow that has come from Bug Work Item Type looks as follows:
Step 14: From the toolbox drag and drop a State shape below Active state. In the properties of that shape, set the name property to Under Investigation.
Step 15: Select the transition shape in the toolbox. Click on the space below Under Investigation state and drag and drop it over the Under Investigation state. A new transition appears. Reposition it at the convenient location. Right click on it and go to Reasons tab. Change the value of default reason from “.” To “New”. Delete the transition that goes from “ “ to Active State.
Step 16: Again select the transition shape in the toolbox. Click on the state Under Investigation and drag and drop it over the Active state. A new transition appears. Reposition it at the convenient location. Right click on it and go to Reasons tab. Change the value of default reason from “.” To “Defect Accepted”. Create a similar transition from Under Investigation state to Close state. Provide the reason as “Defect Rejected”.
Step 17: Resulting workflow should look like this:
Step 18: Save the work item type definition and close the editor.
Step 19: In the team explorer, select the node of Work Items; right click on it and select New Work Item of the type Defect. Observe all the changes that you had done in the type definition getting reflected in the work item itself.
Summary: In this article, we have viewed the entire process of editing the work item type definition using the Team Foundation Power Tool. Any work item is defined by Fields (data it stores), layout (the way to visualize that data) and workflow (states and transitions supported by that work item type). We have edited all these in this article.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!
Was this article worth reading? Share it with fellow developers too. Thanks!
Subodh is a Trainer and consultant on Azure DevOps and Scrum. He has an experience of over 33 years in team management, training, consulting, sales, production, software development and deployment. He is an engineer from Pune University and has done his post-graduation from IIT, Madras. He is a Microsoft Most Valuable Professional (MVP) - Developer Technologies (Azure DevOps), Microsoft Certified Trainer (MCT), Microsoft Certified Azure DevOps Engineer Expert, Professional Scrum Developer and Professional Scrum Master (II). He has conducted more than 300 corporate trainings on Microsoft technologies in India, USA, Malaysia, Australia, New Zealand, Singapore, UAE, Philippines and Sri Lanka. He has also completed over 50 consulting assignments - some of which included entire Azure DevOps implementation for the organizations.
He has authored more than 85 tutorials on Azure DevOps, Scrum, TFS and VS ALM which are published on www.dotnetcurry.com
.Subodh is a regular speaker at Microsoft events including Partner Leadership Conclave.You can connect with him on LinkedIn