The horrid "There may be problems with the work item type definition" error

If you've changed any work item templates in TFS, you most likely have run into the horrid There may be problems with the work item type definition error. We've run into this error a number of times and it's been caused by a number of things (e.g. local cache out of sync with server, having a group the same name as a state, looking at the system too long ;), etc.).

Anyway, today's horrid There may be problems... error message was caused by having a field REQUIRED in two Team Projects, and not REQUIRED in a third Team Project. When we removed the REQUIRED element from one of the first Team Projects, we got the error in that Team Project. The only way we were able to fix this is first remove the REQUIRED element from the field in question in all Team Projects. Then add it back to the one Team Project that wanted it.

Tracking down this issue was difficult, but since we were only making this one change we knew it had to be related to the field. This is why we make one change and a time and test it out before moving on to the next work item template change. If you make too many in the row and get the error, good luck backing out all the changes to try and figure out which change is the culprit.

While this seemed to fix the issue, we can't seem to reproduce it so unfortunately I don't think I can submit it to Microsoft. Anyway if you run into this situation, try removing all rule elements (e.g. REQUIRED) from the field and then re-add them. That is what seemed to fix this for us.

Teamprise's "Download (Save Locally).." for Attachments Rocks!

In one of our Work Items we have a process where a number of LDAP modification scripts get attached. In a recent request we had 34 files that needed to be downloaded so the end user could run them.

In VS.NET 2005 we had to "Open" each one and save them individually. In Teamprise Explorer, we were able to highlight all the files and select "Download (Save Locally).." which downloaded all the files in about one second.

A very nice feature from the fine folks at Teamprise. Microsoft should add this to their own Team Explorer.

Source Control Usability improvements for Team Explorer and Teamprise - Part 2

Here are some additional observations from end users.

- Diff files at check in

A few users have commented that they like VSS's "Diff" option at check in. I argued that there was not such a function, but then I tried it out and sure enough, that is a nice feature. I've used it a couple of times and found it valuable.

- Show Deleted files in Teamprise

I think this is something that is coming in the future, but I've had one or two users asking why their VS.NET colleague can see deleted files and they can't.

- Undo you check out, but keep changes

In VSS users can "Undo Check Out" and choose "Leave" local changes. As of right now, I think users are making full backups of files as when they do "Undo Pending Changes" their local files are replaced with the server files. Now you could argue VSS gave the user too much flexibility, but I'm not here to argue, I'm must relying information back from what users are doing. Personally, I think providing a "Leave" function is fine like VSS does today.

Source Control Usability improvements for Team Explorer and Teamprise

Good day! Now that we've been up and running in TFS for about five months and have 150 or so users on the system, I thought it would be a good time to aggregate some feedback from the users on how the Source Control experience can be improved.

- Add "Your current project" functionality like VSS has.

In a VSS user's ss.ini file there is a "Project" setting (e.g. Project = $/Development/client") that remembers where the user was in the tree when they last where logged in. When the end user closes/opens Team Explorer and Teamprise Explorer, they have to traverse the tree to get back to the structure they were working in. It would be nice if the tooling remembered where they were, so the user does not need to start over again each time the open the tool.

- Changes between or after labels.

I understand why "Labels" don’t show up in Version History in TFS. Buck Hodges does a nice job explaining the reasons. This being said, there should be an easy way for the end user to quickly answer the question "What changes happened since this label (or better, happened after this label and are not included in this label)". My thought would be to include a tool in the interface (i.e. Team Explorer or Teamprise) where the user can pick a label and then see the changes after it or before it. For us adding the label in the version history would be sufficient, as we don't edit labels we just re-label for a change, but again I understand the issues with doing that.

- Show the date of when the label was first applied (or updated).

Right now, we can't see when the label was applied in the interface (i.e. Team Explorer or Teamprise). In addition to the label name, owner, comment, I think seeing the label date (applied or last updated) would be helpful.

- Change the "User" in the Version History to a friendly name

No one knows that I'm U000124578924. They simply know me as "Noland, Mac (Company)". Yet in Version History, the unique ID is used and thus we have to look the unique ID up in Outlook when we want to see who actually changed something.

- Enabling the Compare selection on files that are not downloaded locally.

I know this problem can be solved via selecting two files in the Version History result window, but as an Administrator I can a number of questions regarding why they have to download the file first before "Comparing" it with another file.

- Allow "Get Latest Version at Checkout" to be a preference setting.

Ii Teamprise we really like the preference setting where a user can select "Get Latest Version at Checkout" instead of having to do a get latest and then check out. Team Explorer should include this setting as well. While it's probably philosophical, I'd like to see the setting be the default. It would avoid a number of merge conflicts in our group.

- Right Click and "Set Working Folder"

Teamprise Explorer makes setting up a workspace mapping easy as a Right Click and "Set Working Folder." Team Explorer should implement this feature as I field a number of questions from Team Explorer users on how to setup their workspaces. Teamprise users never ask.

- Recursive Compare of server files with local files.

Team Explorer with Power Tools 1.2 allow this. I hear Teamprise will have this feature in a future release as well. This is a very nice feature and one our team uses all the time in VSS.

- "Find in Files"

Maybe I'm missing something, but I don't see a "Find in Files" function like VSS had. I've got a number of people asking for this feature. Right now they have to do a Get Latest and then use a separate tool (e.g. Eclipse) to do the search.

- Multiple Source Control trees pointed to one local directory
This is the most common question: "How do I map $/TeamProject/mainline and $/TeamProject/release/7.12 to my c:\Development folder like I do in VSS?" Our answer is, "You can't." That is, unlike VSS you can't have a local directory (e.g. c:\Development) that looks at two Source Control trees. While I can see why TFS did this (e.g. helps you avoid stepping all over yourself) most people want this feature back in TFS.

I'm sure there will be more requests that pop up, but these are the most common questions we've gotten from the user base so far.

"The permissions granted to user 'Domain\UserId' are insufficient for performing this operation. (rsAccessDenied)" in TFS

We've been up and running with TFS now for a few months. We started by using Source Control, then moved onto Team Build and Work Item tracking. We're now trying to implement Reports. Here was our latest issue.

We started off by adding everyone using the TFS Administration Tool v 1.2 as "Contributors" in TFS, "Contributor,Web Designer" in SharePoint, and "Publisher" in Reporting Services. From what we can tell, this action will add each user to the Publisher role in Reporting Services under the "Folder" which is created when the Team Project is created. E.g. Team Project Name = Test123, a Reporting Services "Folder" called Test123 is created.

Unfortunately after doing this, the user base continued to get the error "The permissions granted to user 'Domain\UserId' are insufficient for performing this operation. (rsAccessDenied)". We scratched our heads as when checking "Folder" permissions, the user shows up and has "Publisher" access.

This went on for days (actually months to be honest). After an extra long lunch, I came back to my desk and asked the question "What permissions does the Publisher really have?" You may argue that I should have asked this question long before, but in SQL Lesson 2 they say "Assign the Publisher role to users who will perform all of the tasks provided in the previous roles, with additional permissions for publishing reports and models from Business Intelligence Development Studio." The Browser role is right above this statement.

As it turns out the Publisher had the ability to "author reports or models in Report Designer or Model Designer and then publish those items to a report server", but could not View a report. I'd argue if you can publish a new report to the server, you should be able to View it like Browser right? Wrong.

Maybe we missed something in the TFS setup, but as far as I can tell the "Publisher" role did not have View Folders, View Model, View Reports, View Resources. So when the TFS Administrator Tool setup a Contributor with "Publisher" permissions as the default, we took it - and the documentation - as gospel and thus frustrated end users and administrators alike.

We ended up fixing the problem by appending all of Browser's permissions "View Folders, View Model, View Reports, View Resources" to Publisher and so far the problem is solved.

Outside of the "Lesson 2: Setting Item-level Permissions on a Report Server" documentation being incorrect - or at least ambiguous, I'm not sure if there is anyone to blame here. We should have checked the permissions of Publisher instead of assuming Microsoft's documentation was correct.

All in all, I think the root cause is TFS is laborious to administer and thus causes tons of headaches when trying to implement it. From what I hear, they are working on the administration of TFS v2.0, but until then make sure if you add a user to the Publisher group in Reporting Services, either make sure Publisher has all the permissions Browser has, or add all users to both groups. If you've already got 150+ users setup in TFS, I'd recommend the former so you don't have to edit each user.