Agile SCM Talk

What a long title! Anyway, I didn't add LM until sometime after I had setup my Team Foundation Server 2010 instance. There are 2 important realities to face when you do this:

1. The LM permissions in the process template are not applied because LM was configured when the team project was created
2. There's no UI to set LM permissions (arrrgh)

All you have are the permissions established by the accounts used to setup LM (i.e. TfsSetup, etc...).

Here are the commands I developed to grant permissions to existing team projects after you enable LM for them.

The reality is that project managers need work status in real-time. The TFS Excel reports and web parts are great, but because they are sourced from the TFS SSAS cube the information can be up to 2 hours old.

The User Story goes like this...

Team Foundation Server 2010 includes support for Data Warehouse and Analysis Cube Views.

The company, Amrein Engineering, sells a web part that uses SQL statements to source data.

You can implement this web part very easily to do some very nice reporting of TFS data.

Team Foundation Server 2010 does not support publishing history data to Excel. However, there is an easy work around to this problem.

However, this is limited to the last recorded History comment for a work item. This is what displays in the query return set when the History column is included.

1. Create a query with History as a column
2. Run the query
3. Click the pulldown on the "Open in Microsoft Office" button
4. Select "Send Query to Microsoft Outlook"

If you are logged on to the local machine (not the domain) you will be prompted to enter network credentials when you open MTM to connect to TFS. However, if you receive a connection error when you attempt to run a test case, you may want to try the following work around.

1. Go to the Test Plan
2. Select properties
3. Select you Test settings under Manual Runs
4. Uncheck the ASP.NET Client Proxy collection
5. Save and use that Test Settings Configuration to run a test case

It seems there are many issues that can cause this error. But in my situation it turned out to be a permissions issue.

It appears that other TFS 2010 reports use the service account (i.e. TFSReports) to access SSAS. However, it seems that the burndown chart in the TFS MSF v5.0 Agile Iteration Backlog Excel file passes the current user credentials to SSAS to get chart data. As only the TFSReports account had access, the burndown chart request was denied resultign in the error noted above.

To fix this I:

1. Opened SQL Svr Mgmt Studio on the data tier

Earlier this Summer I had the privilege of working for 16 days onsite at the Microsoft offices in Redmond and Vancouver. The assignment, a "Rangers Sabbatical," is part of the Microsoft Visual Studio ALM Rangers program. It provided me the opportunity to develop a Microsoft Word "Technology Provider" or plug-in for the Visual Studio 2010 ALM Coded UI (CUI) feature. Being onsite I was able to work closely with Microsoft Ranger and Program staff.

There are at least three scenarios that deserve mention:

1. Existing data
It doesn't cause an issue. TFS caches the name->SID mapping in the database. If the accounts go away, existing work items/source control history aren't changed.

2. Checked out files