The current out the box experience of work item searching in Team Foundation Server 2010 involves putting together a query, probably spanning a few rows, and then executing it. Then you may save that query for later as something like “My Bugs” or “Created by Me”. Then you find that you frequently want to tweak those queries to search for other things, maybe you save those too, soon you end up with lots of saved queries cluttering your system.
The Team Foundation Server Power Tools August 2011 release provides a new Work Item Tracking Search feature which aims to address the ad-hoc querying this is currently a little cumbersome in the product.
Out the box in TFS 2010, if I want to search for all work items assigned to me I’d craft a query similar to that below and then press Run.
With the Power Tool I can now just type A=@Me
That’s a lot easier!
I’m not going to repeat the help file, so if you haven’t seen it, its a must read and gets installed with the Power Tools to
- YourInstallPath\Microsoft Team Foundation Server 2010 Power Tools\Help\WorkItemSearch.mht
Given my very simple dataset of two work items (one bug and one task) let’s see what we can do to find them
Its worth remembering the shortcuts we can use (as mentioned in the help file)
Find everything assigned to me in a State of new
- A=@me S=New
- A=@me State=New
- A=@me System.State=New These are all the same and provide the single result expected.
Find everything assigned to me of type Bug
- A=@me T=Bug
- A=@me WorkItemType=Bug
- A=@me System.WorkItemType=Bug
- A=@me “Work Item Type”=Bug I would expect these to all be the same, however the second query returns an error
Microsoft Visual Studio
Team Foundation Error
TF26027: A field definition WorkItemType in the work item type definition file does not exist. Add a definition for this field or remove the reference to the field and try again.
Given that System.State worked, this looks like an odd bug. Note that using AssignedTo=@me gives the same error, but System.AssignedTo works.
I’ve done a little testing with other fields and it looks like any CamelCased field will require a full declaration to work. Odd bug, but I think that’s the case . Anyway, it’s easy to work around.
It’s also worth remembering the Operators we can use
|The EQUALS operator. Use this operator to search for exact matches of text.|
|The CONTAINS operator. Use this operator to search for partial matches of text.|
|The NOT operator. Use this operator to exclude work items that contain certain text. The NOT operator can only be used with field names.|
The help files says that by default if we use words “or phrases in quotes” then, “The results displayed contain any work items where your keywords or phrases are found within the Title, Description, or Repro Steps fields.”
I suspect this set was specified for performance reasons. We all know that the history field is what we will most likely need to search to find that work item which does not want to be found. Since we can actually search any field and use operators, this is easily done.
Find everything assigned to me of type Bug where the History filed contains the word sunny
A=@me T=Bug History:sunny
Hopefully that gives you some ideas on how to make use of this feature. Take care to not use spaces between operators and fields, e.g. A= @me will not work. Note the space between = and @. Also note that the search bar will remember your history.
Again, those folk who have spent their spare time getting this too us should be commended. I look forward to seeing better integration and features in TFS11. It would be nice to pin some of those searches wouldn’t it…