views:

598

answers:

3

We have just started out with Team Foundation Server 2008 / Visual Studio Team System and we are pleased to find how we can export and modify work items to our needs. However, this last thing that would make the setup perfect for us has proved somewhat difficult:

We have exported the Bug work item type and have made modifications to it to appear differently to different groups of users. We do, however, see a potential problem in non-developers reporting bugs which turn out to be duplicates. We would like to enforce that users who close a ticket with resolved reason:duplicate also creates a link to the bug which is perceived as the first bug report.

I have looked at System.RelatedLinkCount, and put the rule

  <FIELD type="Integer" name="RelatedLinkCount" refname="System.RelatedLinkCount">
    <WHEN field="Microsoft.VSTS.Common.ResolvedReason" value="duplicate">
      <PROHIBITEDVALUES>
        <LISTITEM value="0" />
      </PROHIBITEDVALUES>
    </WHEN>
  </FIELD>

However, when I try to put anything in that scope, the importer tells me that System.RelatedLinkCount does not accept the rule, no matter what I put, but the rule above shows what I am trying to do (even though the most preferable rule would also check that the bug that I link to is not a duplicate as well, though this is overkill :P)

Has anyone else tried to enforce rules like this in work items? Is there another approach to solving the same issue? I am thankful for any thoughts on the matter.

+1  A: 

I am not sure about preventing this directly on resolving the bug as duplicate. Even with the idea you are working on there is no validation of the link being to an actual bug.

What you might try instead is to write a report that verifies that any bug resolved duplicate has a related link that goes to another bug. Have the responsible team members review this report once a week or so. A little good natured "blame and shame" goes a long way towards keeping a project clean. ;)

Rob McCready
A: 

Doing exactly what you want is pretty difficult in current versions of TFS. (2010's advanced linking makes it easier.) I believe you'd have to write your own link type at minimum, and maybe a custom field control as well. Those interfaces are not terribly well documented on MSDN, though there do exist examples on 3rd party blogs.

The best compromise solution IMO is to create a new integer field called "duplicate bug ID." When a bug is transitioning into the Resolved state and the Resolution field is "duplicate", this field becomes required. All other times, it is read only (and empty by default). This way, all of the information you desire is captured. The downsides are:

  • the "link" isn't bidirection; no way to see from the original bug that a later one was duped against it
  • navigating to the original bug from the dupe requires CTRL+G instead of doubleclicking

I think those are minor for a quick solution that meets 90% of the remaining requirements.

Richard Berg
A: 

You can accomplish this by creating a "buddy" string field that sets its value according to the RelatedLinkCount, then enforce rules on the buddy field according to the resolved reason.

Aidan Ryan