Teams WIT Tools

Customizing Work Item Link Types in TFS 2010

A long time ago (almost 2 years ago), I blogged about how to customize link types. Since the Beta1 has been released, I thought it would be useful to reblog this information.

Here are the links. The information is still valid.

• Rosario - Customizing Link Types Primer
• Rosario: Filtering link types on a work item form

The dates of these blogs will give you an idea of how long we’ve been using these new link types internally.

Enjoy.

Forward Compat GDRs for Team Foundation Server 2010!

TFS will be providing a General Distribution Release (GDR) to enable older versions of Visual Studio Team System Team Explorer to work with 2010 TFS. Releasing these GDRs will allow teams to move forward even when some people are not ready due to legacy code or business intelligence issues.

We will support both Team Explorer 2008, and now Team Explorer 2005 clients!

We are still working on scope and schedule for the 2005 client GDR, but we are well on the way for the 2008 Forward Compat GDR and it will be ready by TFS 2010 Beta 2.

The objective of the GDR is to continue to provide the experience of the 2008 client when working against a 2010 server. New functionality will require the 2010 client, but scenarios you already were able to perform in 2008 will continue to work.

An example of new functionality is hierarchy trees utilizing parent/child link types. Queries in 2010 allow you select all of the work items in the tree. The older clients do not know how to parse the new query code, but clients with the GDR will allow you to recognize the queries that are not enabled for the 2008 client. You can see from the snapshot on the right, the user is able to quickly tell which queries they can use with the 2008 client. If the customer, still tries to open one of these queries they are provided an error message that indicates they need to use a 2010 client or Team System Web Access to view or edit the query.

In addition to this example, several other scenarios have been enabled.

Work Item Tracking

1) TFS 2010 provides flexibility to change the location of your Project Portal, Shared Documents and Process Guidance. The 2008 Forward Compat GDR will retrieve the new location from the server and this allows the 2008 client to continue to navigate to the new locations.

2) With the addition of the Team Project Collection, the reporting server paths have changed for the Team Project RDL Reports. The GDR also enables the 2008 client to navigate to the reports new location.

Office Integration

3) The addition of hierarchy in TFS 2010 has created some portability issues with MS Project plan documents created using a 2010 client when sent to a use with the 2008 client. The GDR enables the 2008 client add-in to update values but not to change link relationships like hierarchy and dependencies.

Version Control

4) The GDR enables the 2008 client to correctly view, update, undo, and commit pending changes, mostly centered around rename scenarios when working with the 2010 server.

5) The user can also correctly view committed changes in both the changeset details and Source Control Explorer.

6) The 2008 client with the GDR will also display accurate messages during conflict resolution.

Test Case Management

7) Test Case Management is really fantastic in TFS 2010 with Test Essentials and we want the customer using TE 2008 to participate, so the new Repro Steps control has been enabled. The Test Steps Control and the Associated Automation Control are viewable in a read only mode providing the user context from Team Explorer.

8) The ability to publish test results from Visual Studio using the Test Result Publishing Server and from the MS Test Command Line Tool are also enabled rounding out the test case management story.

As you can see, this provides a whole lot of goodness to using the Team Explorer 2008 with your new or upgraded Team Project on TFS 2010! Continue to look here to follow our progress for the Compat features.

SharePoint Integration in TFS 2010 Beta1

Last month, Brian Harry outlined some of the new features in the setup and administration experience for TFS 2010 here. This post drills into how SharePoint integration works for Beta1.

Installation

In TFS 2010, we’ve separated the installation from the configuration of TFS. The installation and configuration of SharePoint occurs during the configuration stage of TFS. This addresses a pain point we’ve heard from customers using 2008, where if for some reason, installation or configuration of SharePoint failed, the entire installation of TFS failed as well and rolled back.

When installing TFS 2010, you can choose to install:

Team Foundation Server – Choose this option if you are planning to either deploy only TFS on this box or keep SharePoint and TFS on the same box.

Extensions for SharePoint Products and Technologies – Choose this option if you have SharePoint already installed on the box and want to enable integration with TFS on another server. (Note: this option will not appear if you do not have SharePoint already installed.) This option supports both single-server and farm environments.

User Accounts/Permissions

Our SharePoint integration is much more flexible in 2010, but with this flexibility comes a bit more complexity. If you want to integrate SharePoint with TFS in 2010, then you need to create a two-way mapping: the TFS instance must know where the SharePoint instance is and vice versa. Depending on how you configure SharePoint, the same may hold true of the service accounts. That is, the TFS service account will need access to SharePoint (it must have farm administrator privileges) and the SharePoint service account will need access to TFS.

There are two main scenarios in installation:

• Scenario A: as a TFS administrator, you are in charge of both TFS and SharePoint.
• Scenario B: as a TFS administrator, you do not have control over SharePoint. For example, this may be the case if SharePoint is managed in a corporate farm.

Scenario A is the simpler of the two, and if you’re installing TFS and SharePoint on the same server, then your setup can become even simpler, as you’ll see below. In Scenario B, you’ll need to work together with your organization’s SharePoint administrator to integrate TFS and SharePoint. The TFS installation help file includes a useful worksheet that helps you and your SharePoint administrator collaborate on the information necessary to successfully configure TFS/SharePoint integration, including user accounts.

Configuration

Once the installation succeeds, you’ll move on to the configuration stage. Your options vary depending on whether you installed TFS or the extensions. One of the known issues discussed in the Beta1 ReadMe is a bug that occurs if you choose not to start the configuration wizard right after completing the MSI install (that is, you uncheck the “Launch Team Foundation Server Configuration Tool” option on the setup’s “Finish Page”). Buck Hodges has a great blog post here explaining the issue and how to avoid it.

• Team Foundation Server
  • Default Configuration
    
    
    This is the option you should choose if you plan on using a single server for TFS, SQL, and SharePoint. This option installs and configures Windows SharePoint Services (WSS) 3.0 for you, so if you already have SharePoint installed on the server or want to use Microsoft Office SharePoint Server (MOSS), you’ll need to run the custom configuration. Otherwise, just provide TFS with the details on the service account you want to use for SharePoint, and TFS will do all the installation and configuration for you. 
    
  • Custom Configuration
    
    
    
    This option allows you to customize various aspects of the TFS configuration. By selecting this, you can:
    • Opt out of installing/configuring SharePoint. To opt out, just uncheck the “Configure Sharepoint…” checkbox.
    • Install and configure WSS 3.0 on the server to integrate with TFS. While the Default Configuration does this for you as well, we offer this choice in custom configuration since you may wish to customize other, non-SharePoint related options. As in the Default Configuration, you’ll need to provide a service account for SharePoint.
    • Integrate TFS with an existing SharePoint site. If you fall under Scenario B described above, you’ll want to use the custom configuration to hook up TFS with SharePoint.
      
  • Application-Tier Only
    
    This is the option you should choose if you separate your application tier from your data tier (your SQL server instance for TFS is on a different server) and you do not want to install/configure SharePoint.
    
  • Upgrade from a previous version
    
    
    You can select an existing SharePoint site you want to integrate with. Note that the instruction text on the preceding page is incorrect. You cannot install SharePoint on upgrade in Beta1.
    
• Extensions for SharePoint Products and Technologies
  
  
  There’s not much to configure on this page. :) Just press “Configure” and you’re done.

TFS/SharePoint Mappings

The following diagram represents the recommended mappings when integrating with SharePoint.

TFS Instance/SharePoint Web Application

If you chose to integrate with SharePoint during configuration of TFS, this mapping is created for you. On the TFS side, you need the following information to create/edit mappings to Sharepoint Web Apps:

• The service accounts used for the SharePoint Web Application
• The base URL for SharePoint Web Application
• The SharePoint Central Administration URL
• The relative path for the Sharepoint sites for Team Projects

You can change the mappings in the SharePoint Web Applications Node of the Team Foundation Administration Console:

Recall that mappings are two-way. Thus, if you’re customizing the mappings or you’re creating a new mapping in the TFS Administration Console, you’ll need to keep the mappings from SharePoint to TFS in sync as well. If you are not the SharePoint administrator (scenario B, above), you’ll need to work together to create the mappings.

On the SharePoint server, the TFS mappings can be configured in the Extensions for SharePoint Products and Technologies node of the Team Foundation Administration Console. The following information is needed on the SharePoint side:

• The TFS service account, so that this can be added to the SharePoint farm administrators group
• The URL for the TFS instance
• For MOSS administrators: the single sign on name

Again, if you find yourself in scenario B, the TFS installation help file for Beta1 has a handy worksheet that you and your SharePoint administrator can use to make these mappings a smooth process.

Team Project Collection/SharePoint Site Collection

In TFS 2010, we’ve introduced the concept of a Team Project Collection (TPC). Brian Harry has a great blog post that defines and describes this key concept. You can create TPCs in the Team Foundation Administration Console. If you have SharePoint integration set up and you create a TPC, TFS can create and configure a new SharePoint site collection for you that maps to the TPC (the TFS service account must be added to the SharePoint farm administrator group for this to be successful).

Note that with this integration, you get the added bonus that, if you want to backup/restore your Team Project Collections, you can also backup/restore the corresponding site collections through SharePoint’s own backup/restore mechanism. This allows you to take full advantage of our support for moving TPCs to different servers.

Team Project/SharePoint Site

As with TPCs, if you have SharePoint integration set up and you create a Team Project, TFS can create a correlating SharePoint site that serves as the new Team Project’s portal page.

If you click “Configure…”, you can choose where you want to create the new SharePoint site:

While we give you flexibility here as far as the location, we recommend that you keep the location as a subsite of the project collection to enable the backup and restore scenario we mentioned earlier.

Note that if you wish, you don’t have to create the Process Guidance. You can configure the location of the process guidance later in the Project Portal Settings. This way, if multiple projects are using the same process, you can have them share the same guidance. Instead of updating the guidance for each project, you can now update it in one place.

Finally, in keeping with our theme of added flexibility, there’s an option not to create a SharePoint site at all. You can configure where the portal is later by entering the relevant data in the Project Portal Settings dialog. The dialog allows you to choose whether you want to use a SharePoint site (where TFS can easily integrate its reports and dashboards) or a fully qualified URL of your choice. The same goes for the process guidance.

Useful links

Beta1 install help file (.chm) - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2d531219-2c39-4c69-88ef-f5ae6ac18c9f

Brian Harry: TFS 2010 Admin, Operations & Setup Improvements - http://blogs.msdn.com/bharry/archive/2009/04/30/tfs-2010-admin-operations-setup-improvements.aspx

Buck Hodges: TFS 2010 Beta 1: Don’t run initial configuration from the administration console (MMC) - http://blogs.msdn.com/buckh/archive/2009/05/18/tfs-2010-beta-1-don-t-run-initial-configuration-from-the-administration-console-mmc.aspx

Team Explorer 2010 Beta 1 Compatibility

Although many scenarios have been enabled in the VSTS Beta 1, there are a number of compatibility issues which are still being working on.

 

 * List of Known Issues and Workarounds

1) Team Foundation Server 2010 administrative functions are only supported using Team Explorer 2010.

Problem Statement

As Team Explorer 2008 and Team Explorer 2005 are not aware of several Team Foundation Server 2010 features, administrative functionality has been limited to Team Explorer 2010. For example, the administrator can only run the Project Creation Wizard from Team Explorer 2010 to add Team Project to Team Foundation Server 2010. Team Explorer Team Explorer 2010 client can also be used to administer the Team Foundation Server 2008 server.

Workaround

Use Team Explorer 2010 to perform administrative functions on Team Foundation Server 2010.

2) How to connect a Team Explorer 2008 SP1 to a Team Foundation Server 2010 Server

Problem Statement

Team Project Collections, new to Team Foundation Server 2010, change the path to the server.

Workaround

We can express the connection string as follows:

http://<serverName>:<port>/<vdir>/<collectionName>

Where the <vdir> is an optional, server level argument.

Example connection Strings looks like: http://myserver:8080/Collection1 or http://server:8080/tfs

Moreover customers can give the server name (using the Team Explorer 2008 way to create the connection string) to connect to default collection of the instance on that server.

3) How to connect Team Explorer 2010 to Team Foundation Server 2008

Problem Statement

The path field in the connection dialog is defaulted to Team Foundation Server

Workaround

Team Explorer 2010 connection dialog may need the path field cleared to connect to a previous version of Team Foundation Server.

4) Test Results Publishing is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Test case results cannot be published using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to publish test case results.

5) Rename in Version Control is not supported for Team Explorer 2008 SP1 or older clients.

Problem Statement

Rename in Version Control can cause unexpected results using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to use rename in Version Control.

6) Work Item Tracking Queries with new functionality are not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Work Item Tracking Queries with new functionality create unexpected error messages.

Workaround

Place new queries with linking, grouping, categories, or field comparisons in a separate folder marked “New Clients Only” so customers using Team Explorer 2008 SP1 or older clients can distinguish those queries without these features.

7) Navigation to Reports is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Team Explorer 2008 SP1 or older clients do not recognize the path to the reports for a Team Project hosted on Team Foundation Server 2010.

Workaround

Use a browser to navigate to the http://<reportserver>/reports then click on the “Team Foundation Server Reports” folder and the Team Project Collection folder for the appropriate collection that contains the Team Projects you are interested in.

8) Navigation to non-default Shared Document, Project Portal and Process Guidance locations is broken for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Administrators are able to configure the location of the Shared Documents, Project Portal and Process guidance but Team Explorer 2008 SP1 Client will not be able to find the new location.

Workaround

If the Shared Document, Project Portal and Process Guidance locations have been modified, URLs to the new locations can be sent to the customers with Team Explorer 2008 SP1 Clients or older clients.

9) Microsoft Project plan documents created using a Team Explorer 2010 client, break when opened from a Team Explorer 2008 or older client.

Problem Statement

Customers who open a Microsoft Project plan created from a Team Explorer 2010 client with a Team Explorer 2008 or older client will cause the plan to become unusable.

Workaround

Do not port project plans to other Microsoft Project tools using older client add-ins during Beta 1.

10) Team Explorer 2008 or older client will not be able to manually queue a build without having the “View Build Resources” permissions.

Problem Statement

Build permission on upgrade were not automatically set to enable Team Explorer 2008 or older client users.

Workaround

Contact the Team Project Administrator to have the build permissions elevated for Team Explorer 2008 client users, if no build agents are visible in the Queue Build dialog in Team Explorer 2008.

11) Team Explorer 2008 or older clients will not be able to manage build resources using the “Manage Build Agents” dialog box.

Problem Statement

The “Manage Build Agents” dialog box disabled for the old client user and users get the following error message when trying to edit, add or delete: “Updating build agents is not supported from this client. Please use a client compatible with Team Foundation Build Codename Rosario and try again.”

Workaround

Use Team Explorer 2010 to manage build resources.

12) Team Explorer 2008 or older clients will be able to submit changes that affect gated build definitions, but they will not be prompted with the confirmation dialog and, if their check-in affects multiple gated definitions, it will fail.

Problem Statement

The customer may not know if they were successful or not.

Workaround

The customer can check the build explorer (just like a Team Explorer 2010 user would) or use the build notification applet (2008 power tools release rather than 2010 release).

13) Team Explorer 2008 or older client users can create new build definitions but they will not be able to edit them or to edit other, existing build definitions.

Problem Statement

New build definitions will be automatically upgraded to Team Foundation Server 2010 build definitions using the upgrade build process template, so Team Explorer 2008 or older client users will not be able them.

Workaround

Use Team Explorer 2010 Client to get the WF designer experience or to edit build definitions or use a text or XML editor to edit the build process template.

Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes

Team Foundation Server 2010 is a BIG release for us by all counts. We have made conceptual changes; Brian introduced some of the key concepts in TFS 2010 that includes the concept of Team Project Collections (TPCs). These changes required a lot of infrastructure support that we built from the ground up and changes to all the subsystems including the warehouse adapters, relational warehouse schema and the Analysis Services cube schema.

As our Beta 1 release approaches, I wanted to outline the changes to the relational warehouse and cube schema. These are, unfortunately, breaking changes. While we will provide an updated set of out-of-the-box reports (details below), these schema changes will affect your custom reports. By custom reports, I mean SQL Server Reporting Services (SSRS) or Excel pivot table/chart reports you may have authored against the warehouse or cube.

First, a bit of history

We get a lot of validation about the incredible value that our reporting platform provides. But, we also know that SQL Server Reporting Services (SSRS) reports aren’t easy to build. In our previous releases, we had our Analysis Services cube as the only supported interface for report authoring. However, we recognize that MDX has a huge learning curve for building complex reports using SQL Server Business Intelligence Development Studio (BIDS) and that ad-hoc reporting with Excel pivot table/chart or SQL Server Report Builder didn’t go very far.

While the SSRS team has made great improvements in Report Builder 2.0 when compared to the previous version and they continue to invest in making it easier for end users to author reports, we had work to do as well.

Here are some of the main reasons we invested in improving the schema:

• Infrastructure support
  • We had to make changes to support infrastructure changes such as the concept of Team Project Collection (TPC). For example, we used to have a flat list of Team Projects in 2008 and the project names were guaranteed to be unique on a server. However with TPCs, multiple collections could have project with same names. This poses a problem as multiple collections feed into the same warehouse and cube. Since TPC is a collection of Team Projects, Team Project dimension had to support hierarchy as well.
  • If are you wondering why not have a one warehouse and cube per collection, read the next bullet point.
  
  
• Cross-Team Project Collection reporting
  • In 2008, we had a flat list of Team Projects on a server and because all of these feed into a single warehouse and cube, you could report across projects. We had to make changes to continue feeding data from multiple collections into the warehouse and cube to support cross-TPC reporting.
  • This direction lines up with our future goal to support multiple warehouses and continue to support cross-TPC reporting where you choose which collections feed into which warehouse. While, we won’t get there in 2010, this enables us to work towards that goal. In TFS 2010, you do get the flexibility to choose whether you want to use reporting or turn it off.
  
  
• Enabling relational warehouse as reporting interface
  • As I mentioned before, we used to have the cube as the only supported interface for report building. MDX has a huge learning curve so it was a big investment for our customers who wanted to build reports.
  • In TFS 2010, we wanted to provide views as the supported reporting interface on top of the relational warehouse as people have T-SQL knowledge. Our old naming conventions didn’t help differentiate fact tables from dimension tables. We had work to do to clean up the schema. So, while we updated the schema to support infrastructure changes like adding TPC information to these tables, we also standardized table names.
  
  
• Cube usability
  • Our old cube schema wasn’t very usable as we had a *lot* of top-level dimensions so it wasn’t easy to understand how they relate.
  • We create perspectives and they definitely help, but that feature is limited to SQL Server Enterprise Edition.
  • Our work item tracking subsystem has a dynamic schema which is very flexible. But this poses a problem in the cube because custom date and person fields that are added to the system and marked reportable end up as top-level dimensions potentially making the list very long and hard to understand.
  • Some of the fields were only related to work item tracking, like Area and Iteration, but were top-level dimensions alongside other dimensions like Build that weren’t related.

Cube Schema Changes

Here’s a comparison between TFS 2008 and TFS 2010 using the default list of dimensions that are created:

TFS 2008	TFS 2010

Here are the main changes to the Team System cube in TFS 2010:

• Date and Person fields are now attributes on the Work Item dimension rather than being top-level dimensions.
• There is still a top-level Date dimension that you can use for building trend reports that combine measure from multiple measure groups like work items and test results.
• Area and Iteration dimensions have been folded into the Work Item dimension as true hierarchies and are 14 levels deep similar to Work Item Tracking (WIT) operational store.
• Agent Machine information is now available in the Machine dimension.
• Some dimension names have been updated to make them more meaningful and provide context especially when looking at the entire list. Here’s a mapping for the name changes:
  
  

  Old Name	New Name
  Counter ID	Load Test Counters
  Page Summary	Load Test Page Summary
  Platform	Build Platform
  Flavor	Build Flavor
  Run	Test Run
  Source Project	Source Project File

  
  
• Result dimension has been replaced with Test Result dimension because of schema changes in the Team Test operational store.
• Outcome dimension has been folded into Test Result dimension.
• Run By dimension folded into Test Result dimension.
• Owner is no longer a top-level dimension but part of Test Result and Load Test Result.
• Dimensions starting with ‘Related…’ are available in the Linked Work Item dimension.

Here are the main additions to the Team System cube in TFS 2010 to support the new functionality that is available:

• Work item hierarchy and linking, new in TFS 2010, is also supported in the cube. Related link is no longer the only link type available in WIT and there can be single-hop links or tree link types. Single hop links are available in the Linked Work Item dimension and tree hierarchy is available in the Work Item Tree dimension.
• In TFS 2010, work item types can now be grouped into categories. For example, ‘Bug’ category can group ‘Bug’ work item type and ‘Defect’ work item type. This information is available in the cube in the Work Item Category dimension and enables cross-project reporting across different work item types that belong to the same category. 
• Test cases are stored as work items in 2010, these test cases are available as Work Item Test Case dimension. This dimension filters on just test case work items.
  • The name of this dimension is subject to change post-Beta 1.
• Test Suite, Test Plan and Configuration are new Team Test concepts represented by these new dimensions.
  • Note that Test Suite is not available in the cube in Beta 1.
• Area Path and Iteration Path are now available as attributes on the Work Item dimension that provide a flat string to be displayed on your reports.
• We also added display folders to the Work Item dimension to make it easier to group fields rather than display one long list
  • The names of display folders are subject to change post-Beta 1. If you have feedback, please leave a comment or send me an email at sunder.raman at microsoft.com 

  

Relational Warehouse Schema Changes

Though our relational warehouse database was not a supported reporting interface, we have made some changes that are worthwhile to mention for customers who are going directly against this database to author reports.

Here are the main changes to the relational warehouse database in TFS 2010:

• TPC information has been added to tables as appropriate
• We have created views on top of the relational warehouse to provide reporting interface.
  • These views make it easier to query for data and less likely to break reports when moving to future versions.
  • The views available in Beta1 are pending some design decisions. So, please note that these views are subject to change post-Beta1.
• Naming conventions have been standardized to help differentiate fact tables and dimension tables

  TFS 2008	TFS 2010

Out-of-the-box reports

In TFS 2010, we will ship a brand new set of out-of-the-box SSRS reports that work against the new schema. We also authored these reports as Excel workbooks that will ship with the product as well. These Excel workbooks will “light-up” with our new dashboards in TFS 2010; for customers who use Microsoft Office SharePoint Server (MOSS). These new Excel workbooks will also be available for customers who choose Windows SharePoint Services (WSS). Look for more information about the dashboards in a subsequent post by one of my colleagues.

In addition, to make it easier for customers using SSRS reports that shipped with TFS 2008, we are also updating TFS 2008 reports to work against the new schema changes as well. These updated reports will ship as part of TFS 2010.

We are planning to release a whitepaper to help convert your custom reports to work against the new relational warehouse and cube schema. Stay tuned. We always welcome your feedback! Please leave a comment on this post or send me an email at sunder.raman at microsoft.com.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder]

Previous State and State Change Count

Today I am going to look at two interesting fields in the Warehouse related to Work Items – Previous State, and State Change Count.

The Previous State field stores the state a Work Item was in before it entered its current state.  This field is in the [Work Item] table in the relational/dimensional Warehouse and in the [Work Item] Dimension in the Cube.

The State Change Count measure counts the number of changes in State between a Work Item revision and its previous Revision (actually instead of 0 it will have a value of NULL – so it will either have a value of 1 or NULL).  It is in the [Work Item History] table in the relational/dimensional Warehouse and in the [Work Item History] measure group in the Cube.

The easiest way to understand their values is with an example.  In this example we are going to create a new Work Item and then edit it several times.  The table shows the values in the Warehouse (of course all of these are not in the same table in the Warehouse – but showing it like this makes the example simpler).

1.       Create a new Work Item.

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1

 

The Previous State is NULL because prior to Revision 1 the Work Item had no state.  The State Change Count is 1 because the Revision changed from state NULL to state Active.

2.       Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2

 

The State the Work Item was in, before it was in its current state, is still NULL.  The state of Revision 2 didn’t change from Revision 1 so the State Change Count is NULL.

3.       Modify the state (i.e. Resolve the Work Item)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3

 

Now the State the Work Item was in before it was in its current state is Active.  The state changed so the State Change Count is 1.

4.       Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4

 

5.       Modify the state (i.e. Reactivate the bug)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4
1	5	Active	Resolved	1	1/5

 

Alright I think it is clear what the values will be for these fields… now what good are they?

The Previous State serves as a cache of state the work item before it entered the current state.  Without this one would have to walk back work item revisions until you found one that had a different state.  The Previous State can be used to answer questions like:

For my Work Items that are currently Active, how many of them have been reactivated (Previous State = Resolved)?  A large number of reactivated Work Items may indicate developers are not doing enough unit testing.

The State Change Count gives us a way to quickly identify revisions where the state changed.  Using this along with the Previous State you can identify things like resolved rates per day or incoming rates per day.  For example if you looked for Work Item revisions with State = Resolved, Previous State = Active, and State Change Count = 1 you would get those revisions that were resolved – and the dates.  Note that if a work item was reactivated then resolved again you would get it back two times – this may or may not be what you want for your report.

[Cross Posted from blogs.msdn.com/nericson]

Work Item rules workaround: Cannot close task unless Remaining Work is zero

In the last post in this series, Gregg blogged about restricting a bug such that only the creator can close it. This is the last post in this series of workarounds that we have been blogging about. We saved this as the grand finale for our series.

 

Customers have asked us: “I don’t want to allow users to close a task unless they have set Remaining Work to zero”

 

Here’s the solution:

1. Create a RemainingWorkValidation field

2. Add it to the form definition under the validation tab like the previous examples

3. Add the following rules to the RemainingWorkValidation field

<FIELD type="String" name="Remaining Work Validation" refname="Demo.RemainingWorkValidation">
  <ALLOWEDVALUES>
    <LISTITEM value="No Errors" />
  </ALLOWEDVALUES>
  <WHEN field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
    <COPY from="value" value="No Errors" />
  </WHEN>
</FIELD>

4. Add the following rule on the transition to closed state

<Transition from="Active" to="Closed">
  <REASONS>
    <REASON value="Deferred" />
    <REASON value="Obsolete" />
    <REASON value="Cut" />
    <DEFAULTREASON value="Completed" />
  </REASONS>
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
        <COPY from="value" value="Remaining work has to be zero before closing the work item" />
      </WHENNOT>
    </FIELD>
  </FIELDS>
</Transition>

5. Add the following rule to active state

<State value="Active">
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <COPY from="value" value="No Errors" />
    </FIELD>
  </FIELDS>
</State>

 

6. Add the following rule to closed state

<State value="Closed">
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
        <COPY from="value" value="Remaining work has to be zero before closing the work item" />
      </WHENNOT>
    </FIELD>
  </FIELDS>
</State>

 

Here’s what it looks like:

A word of caution, one of our readers ran into an issue with Team System Web Access with the previous closing an iteration workaround where the UI doesn’t refresh on WHEN rule. Though I haven’t had a chance to try this workaround using Web Access, the WHENNOT rule used here may have a similar issue in Web Access.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder]

Work Item Rules Workaround: Only the creator of the bug can close the bug

In our last post in this series, Sunder blogged about saving the resolved reason. (You’ve probably figured out that we have “tag-teamed” this blog series). So anyway, here is the next item in the series.  Customers have asked us:

“I only want the creator of the bug to be able to close the bug … no one else”

“Oh … and by the way, I want to be able to have an administrator override and close a bug for anyone”

Another valid request, again which is not handled well with standard implementations of work item rules. In fact, Sunder and I tried and tried to figure this one out, and simply couldn’t come up with a solution.

Then I offered a $5 reward to a developer who said he could figure it out. Well I’m out $5, but now have something to offer to solve this problem. Worth the $5? You can be the judge…

 

Here are the steps:

1) Create ClosedByValidation field and add the following rules:

<FIELD name="Closed By Validation" refname="Demo.ClosedByValidation" type="String">
    <COPY from="currentuser" />
    <FROZEN not=“[project]\Project Administrators”/>
</FIELD>

 

2) Add the following rules to Closed state

<STATE value="Closed">
   <FIELDS>
      <FIELD refname="Demo.ClosedByValidation">
          <COPY from="currentuser" />
       </FIELD>
   </FIELDS>
</STATE>

3) Add the ClosedByValidation field to the form, so it looks like this. Note how I’ve displayed both the “Created By” field and the “ClosedByValidation” field.

 

How it works:

• The ClosedByValidation field copies the “Created By” value into itself right when the work item is created.
• It then immediately freezes the field (with the FROZEN) rule, which states that it cannot change.
• NOTE: The FROZEN rule is conditioned to NOT apply to project administrators, giving them an override capability.
• When the work item is Closed, then the current user is copied into the ClosedByValidation field.
• If the ClosedByValidation’s value remains the same (the original Created By) then all is well.
• If the ClosedByValidation’s value has changed, then the FROZEN rule displays a violation as you see in the screenshot above.

Pretty clever Mr. Developer.

CodePlex Tool: WIT Synchronizer

I just saw that Loic Baumann posted a tool on codeplex called WIT Synchronizer. It provides two pieces of functionality that has often been requested.

“I’ve made a change to my Process Template, how do I push those changes to existing projects”

“I’ve made some updates to my process in an in-flight project, and now want to update my Process Template with those changes”

I haven’t played around with this yet, but have plans to. I just wanted to get the word out.

Once I’ve played with it, I’ll let you know the results.

Work Item rules workaround: Saving the resolved reason

In our last post in this series, Gregg blogged about securing a work item type. Another question along these lines: “How can I save the resolved reason? I want to create metrics based on how bugs were resolved, but the value of the ‘Reason’ field is changed when the bug is closed”

Here’s the solution:

1. Add “Microsoft.VSTS.Common.ResolvedReason” field to the form definition

2. Add the following rules to the workflow transition from “Active” to “Resolved”

<Transition from="Active" to="Resolved">
   <REASONS>
    <REASON value="Fixed">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
          <COPY from="value" value="Fixed" />
        </FIELD>
      </FIELDS>
    </REASON>
    <REASON value="Deferred">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
          <COPY from="value" value="Deferred" />
        </FIELD>
       </FIELDS>
    </REASON>
    ...
</Transition>

Here’s the end result; I am displaying the field in the Details tab of the Bug form:

This workaround works by copying the resolved reason when the bug is resolved off into the Resolved Reason field.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder/]

Work Item Rules Workarounds: Secure creation of a work item type

In our last post in this series, Sunder blogged about Deactivating a work item type. Here’s another popular request: “Secure creation of a work item type”. For example, people say:

• “Only my Testers can create bugs”
• “Only my Business Analysts can create Requirements”

This is a legitimate request and we don’t have a good answer in Work Item Tracking, but do have AN answer.

First you add the following rules to the default transition.

<Transition from="" to="Active“ for=>
  <REASONS>
    <DEFAULTREASON value="New" />
  </REASONS>
...
</FIELDS>

   <FIELD refname="System.State">
      <READONLY not="[project]\Business Analysts" />
   </FIELD>
  </FIELDS>
</Transition>

The group “[project]\Business Analysts” should then be populated with the users that can create this work item type.

Now if a user who is NOT in the group attempts to save a work item of that type, this is what he/she will see:

This is the approach we’ve found that works the best. But be aware of these issues:

• It doesn’t prevent a non-approved user from creating a work item of that type, only from saving the work item of that type. Not the best experience.
• The error message, of course, isn’t the best.

But it does do its job.

Someone who many have tried to solve this problem before, may be asking. Why aren’t we using transition security? Transition is the ability to allow only certain users to make a transition between work item states. Using this method, you would do this:

<TRANSITION from=“" to=“Active"

     for="[project]\AllTesters" not="[project]\Business Analysts">

</TRANSITION>

The reason we didn’t like that method, is because of the error message you received:

“The field ‘State’ contains a value that is not in the list of supported values”

So … when choosing a method, we chose the one that displayed the error message closest to what we’d like to show.

That’s it!

Work Item rules workaround: Deactivating a work item type

In our last post in this series, Gregg blogged about forcing selection of reason. Let’s take a look at another question that we often get: “How do I deactivate/retire a work item type? I don’t want to destroy the type because I want to report on it, but I don’t want others to create new work items of this type”.

Using a similar approach to the previous workarounds:

1. Create a DeactivatedType field as part of the type you want to deactivate
2. Add the following rules to the field:

<FieldDefinition type="String" name="Deactivated Type" refname="Demo.DeactivatedType">

  <COPY from="value" value="This work item type has been deactivated. Use Bug type instead." />

  <PROHIBITEDVALUES>
    <LISTITEM value="This work item type has been deactivated. Use Bug type instead." />
  </PROHIBITEDVALUES>

</FieldDefinition>

 

Now, add this field to the form definition. Make it prominent, let’s put it at the top of the form. Here’s how the form would look like when a user tries to create a work item of this type:

 

This workaround works by copying a value to our new field that violates the prohibited values rule, so the new work item cannot be saved. This achieves the net result that your type hasn’t been deleted but work items of this type cannot be created.

Sunder Raman

Program Manager, Team Foundation Server

[Update 3/31/2009]: Cross-posted on http://blogs.msdn.com/sunder/

TFS Warehouse Work Item Tracking Compensating Records

Compensating Records

What are compensating records?

[Cross Posted from blogs.msdn.com/nericson]

Work Item Rules Workarounds: Force selection of Reason

In our last post in this series, Sunder blogged about Closing down an iteration. Let’s take a look at another question: “How do I force people to select a reason?”

We’ve had people come to us with the request to force their users to select a reason. The way State/Reason is implemented, there is always a default Reason. Therefore, its very easy for a user to just change the state, and accept the default Reason without thinking. Our customers wanted people to have to make a choice.

In the above example, the customer wants the Reason field to be blank by default.

Here is the workaround. The steps are:

1. Create a ResolvedReasonValidation field

2. Create a Form tab called “Validation Errors” and place ResolvedReasonValidation on it

3. Add a default Reason: “Select a reason” and a COPY rule on Resolved state

4. On each non-default reason, add a COPY rule

 

5. Add Rules on ResolvedReasonValidation

 

Put it all together, and this is what it looks like:

Work Item rules workaround: Closing down an iteration

In our last post in this series, Gregg blogged about validating area path. Let’s take a look at another question: “How do I close an iteration so that no one can log new items against it?”

For this example, let’s say we have completed Iteration 0 and don’t want users to log work items against this iteration. We also don’t want to allow work items against the root iteration path.

Since there is no direct way to enforce rules against iteration path, here’s how we can work around it:

1. Create an IterationPathValidation field
2. Create a tab on the work item form called “Validation Errors”, like the previous example on area path validation, and display the IterationPathValidation field
3. Find the IDs for the restricted iteration paths
4. Add the following rules to the IterationPathValidation field:

 

<FIELD type="String" name="Iteration Path Validation" refname="Demo.IterationPathValidation">

  <COPY from="value" value="No Errors" />

  <WHEN field="System.IterationId" value="113">

    <COPY from="value" value="Iteration path must be 2 levels deep" />

  </WHEN>

  <WHEN field="System.IterationId" value="115">

    <COPY from="value" value="The selected iteration has been completed. Log bugs against a future iteration." />

  </WHEN>

  <PROHIBITEDVALUES>

    <LISTITEM value="Iteration path must be 2 levels deep" />

    <LISTITEM value="The selected iteration has been completed. Log bugs against a future iteration." />

  </PROHIBITEDVALUES>

</FIELD>

 

 

The next step is to add this validation field to the work item form, let’s use the same form definition as the area path validation example. Here’s how the form would look when a user assigns a work item to Iteration 0:

The IterationPathValidation field shows a meaningful error message when a work item is assigned to the closed iteration.

How does this workaround work?

• IterationPathValidation, like the previous example on area path validation, acts as an error field
• The initial COPY rule initializes this field to “No errors” that is displayed when the rules on the field are satisfied
• The PROHIBITEDVALUES list defines strings that are not valid for this field. We are using these as meaningful error messages as well.
• Using the WHEN rule we can copy the error strings to this field for iterations we want to restrict

How do I find out the iteration ID?

• Assign any work item (without the above rules) to Iteration 0
• Save the work item
• Expand the changed fields section in the work item history field and this will have the System.IterationID as one of the changed fields with the ID of Iteration 0

If you have ideas on other workarounds or scenarios you want to accomplish, please let us know and we will post them here. We have a few more workarounds coming your way in the upcoming posts.

Sunder Raman

Program Manager, Team Foundation Server

 

[Update 4/23/2009] Thanks to one of our readers, Dylan for his comment that this workaround didn't work for him in TSWA. I reproed this workaround and we found the issue where Web Access isn't refreshing on WHEN rule. We are tracking this bug to be fixed in our upcoming release. Caution to users, if you are using TSWA, note that this workaround doesn't work in TSWA.