Hakan has announced the availability of the new TSWA community technology preview (CTP) in his post, What's New in TSWA 2008 SP1.  Personally, I would say this release is beta quality or better, so don't let the CTP designation scare you too much.

Also released is the first CTP release of what we are calling Work Item Web Access (WIWA).  You may recall that we published a spec for it recently, referring to it as a "bug submission portal."  WIWA provides you with the ability to have folks create work items and view work items they have created without needing a client access license (CAL) for 2008.  This was a new condition that was added to the TFS 2008 license agreement.  Hakan has more details in his post on WIWA.

Both the CTP of TSWA and the CTP of WIWA have the same requirements as the previous release of TSWA 2008 (e.g., you must have Team Explorer 2008 installed as a prerequisite).

This release of TSWA has some really great new features.

  • Single instance with multiple languages
  • Support for specifying field values in the URL for creating new work items (works in both TSWA and WIWA)
  • Share ad-hoc work item queries
  • Shelveset viewer
  • Improved search support

I want to call out two features in particular that I really like.

Support for specifying field values in the URL for creating new work items (works in both TSWA and WIWA)

How often have you wanted users or testers to file bugs and needed to have them fill in certain fields with particular values so that the work item shows up in the correct area?  We now support providing field values in the new work item URL.  Here's the example that Hakan provided.

http://<server>/wi.aspx?pname=MyProject&wit=Bug&[Title]=Bug Bash&[AssignedTo]=Hakan Eskici&[Iteration Path]=MyProject\Iteration2&[FoundIn]=9.0.30304

This will open a new work item editor window with the following initial values:

  • Team Project = MyProject
  • Work Item Type = Bug
  • Title = Bug Bash
  • Assigned To = Hakan Eskici
  • Iteration Path = MyProject\Iteration2
  • Found in Build = 9.0.30304

Now you can start sending your users and testers a link with all of this already filled in!

Improved search support

Have you ever wanted to search for bugs assigned to someone in particular or in a particular area without writing a query?  In the past, you could only search the Title and Description fields in a work item, which I described here.  Now you can enter the following into the search box in TSWA to find any bug assigned to me that also has the word "exception" in the Title or Description.

exception a="Buck Hodges"

The core fields have shortcuts.  Any field can be used by specifying the reference name for the field.  Here's the equivalent without using the shortcut.

exception System.AssignedTo="Buck Hodges"

Here are the shortcuts for the core fields.

  • A: Assigned To
  • C: Created By
  • S: State
  • T: Work Item Type

You can use TFS macros, such as @me, in search.  For example, find all work items containing "watson" in the Title or Description that are assigned to me that are in the Resolved state and are work items of type Bug.

watson a=@me s=Resolved t=Bug

Now, if you really want to do something cool, there are the "contains" and "not" operations.  The "=" operator matches exact phrases, whereas the ":" operator is used for "contains" clauses.  The following search looks for bugs assigned to Active (i.e., not assigned to any particular person yet) where the word "repro" is contained in the History field.

a=Active History:repro

This example illustrates the difference between the two operators.  The first example finds all work items where the Title is exactly "Bug Bash" with no other words or characters in it.  The second example, which uses the contains operator (colon) rather than the exact match operator (equals), finds all bugs where the Title contains the phrase "Bug Bash" along with any other words or characters.

  • Title="Bug Bash"
  • Title:"Bug Bash"

Personally, I find myself almost always using the contains operator.

Finally, you need to be able to exclude certain things from your search.  For that, there is the not operator, which is represented by the hyphen ("-").  The following example finds all work items with "watson" in the Title or Description fields that are not assigned to me and that are not closed.

watson –a=@me –s=closed

The not operator only works with field references, so you can’t use the following to find all work items containing "watson" but not containing "repro" in the Title and Description fields.

watson –repro

However, you can accomplish this by specifying the Title field explicitly with the not operator.

watson –Title:repro

Please send us your feedback on both the new features and Work Item Web Access!