Freigeben über

How to Add a Placeholder Account to Your TFS Bug Form For Pre-Triage Bugs

  • Artikel

This question came across Twitter recently, and I had to do a little research to answer it.  I thought I’d pass along what I found in case others are wondering how to do the same thing.

The scenario – You want to add a “placeholder” account to the available list of options in the AssignedTo field so you can assign bugs that have not yet been triaged to this value.  Ideally, you want this to be the default value.  When your team members file bugs, they get assigned to this fake user.  Then, bugs that have not yet been triaged by the team can easily be searched.

Note, this is not the only way to solve this problem.  Other solutions I’ve seen include adding a new state value for bugs called something like “submitted”.  Then, when bugs are accepted by the triage team/process, they’re moved into the “active” or “accepted” state.  If there is sufficient interest, I’ll blog about how to do that.

 

Step 1: Export the work item metadata for the work item type you want to modify.  See this page for details on how to use witexport.exe.  The command I used to export the “Bug” work item type from my team project called “MovieApp” looked like this:

 C:\Program Files\...\IDE>witexport.exe /f bug.xml /t https://jasonba-dev10:8080 /p "MovieApp" /n “Bug”

This command connects to the server jasonba-dev10 and exports the metadata for the “Bug” work item type from the Team Project called “MovieApp” to a file called “bug.xml” in the current directory.

 

Step 2:   Next, open the bug.xml file and find the section of the metadata that defines the “Assigned To” field.  Assuming you created your team project using the MSF Agile template, it would look something like this:

       <FIELD name="Assigned To" refname="System.AssignedTo" type="String" reportable="dimension">
        <VALIDUSER />
      </FIELD>

The <VALIDUSER /> tag means that any member of the Valid Users group is a valid option for the “Assigned To” field.  Unfortunately, this limits you to just those members.  So, since we want to add a placeholder user, we’ll need to remove that tag and change a few other things.

 

Step 3:   Remove the <VALIDUSER /> line (just that line only!) and replace it with the following text:

         <DEFAULT from="value" value="Not Yet Assigned" />
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="[global]\Team Foundation Valid Users" />
          <LISTITEM value="Not Yet Assigned" />
        </ALLOWEDVALUES>

Let’s walk through what these new lines mean.  First, the <DEFAULT…> line specifies that the field should be get to “Not Yet Assigned” by default. 

Next, the <ALLOWEDVALUES…> section defines the set of values that appear in the “Assigned To” list.  The expanditems=”true” attribute means that if you specify a group in the list of allowed values, any sub-groups that happen to be members of that group should be expanded and their members should also show up as options in the list.  The default value for this attribute is true, so it’s really not necessary, but I include it for completeness.

The first <LISTITEM…> line pulls in all members of the global server group called “Team Foundation Valid Users”.  Essentially, anyone with access to the server will now show up in the “Assigned To” dropdown list.

Finally, the second <LISTITEM…> line is what defines our fake user named “Not Yet Assigned” (hopefully you don’t have a real team member with that name!).  Note that this text must match the text you specified in the <DEFAULT…> tag in order for the default setting feature to work properly.

Note, you can add other similar values here, such as “Closed” for bugs that have been moved into the “Closed” state.

 

Step 4: – Upload your template changes back to the server with the witimport.exe command.  For example:

 C:\Program Files\...\IDE>witimport.exe /f bug.xml /t https://jasonba-dev10:8080 /p "MovieApp"

 

Step 5 – Finally, if your import was successful, refresh your Team Explorer window to pick up the changes.  When you create a new bug, you should see the value “Not Yet Assigned” as the default value for the “Assigned To” field.

Comments

  • Anonymous
    February 20, 2009
    PingBack from http://www.clickandsolve.com/?p=12402

  • Anonymous
    February 24, 2009
    The comment has been removed

  • Anonymous
    February 27, 2009
    If you're using the CMMI template, you have a "Triage" field already on the bug, which encapsulates a nice mini-state set for getting bugs going. We query on project, State == Proposed, Triage == Pending. The XML in the template is:      <FIELD reportable="dimension" type="String" name="Triage" refname="Microsoft.VSTS.Common.Triage">        <HELPTEXT>Status of triaging the bug</HELPTEXT>        <REQUIRED />        <ALLOWEDVALUES>          <LISTITEM value="Pending" />          <LISTITEM value="More Info" />          <LISTITEM value="Info Recv" />          <LISTITEM value="Triaged" />        </ALLOWEDVALUES>        <DEFAULT from="value" value="Pending" />      </FIELD>

  • Anonymous
    March 02, 2009
    Thanks so much for this helpful hint!   We were always frustrated with the fact that the <VALIDUSER /> tag pulled in all of the users that had access to Team Foundation Server - not just the people that had access to the project.  Using the logic presented here, I was able to substitute the <VALIDUSER /> tag in all of the user type drop down lists with the project groups.  This really helped in limiting the number of people shown in these lists. Thanks so much!!