[Updated 4 Feb 2013 See http://blogs.msdn.com/b/bharry/archive/2013/02/01/hotfixes-for-tfs-2012-update-1-tfs-2012-1.aspx for the latest on this ]
I posted earlier in the week about my experiences with the post TFS 2012 QU1 hotfix. When I posted I thought we had all our problems sorted, we did for new team projects, but it seems still had an issue for teams on our team projects that were created prior to the upgraded from RTM to QU1. As I said in the past post we got into this position due to trying to upgraded a TPC form RTM to QU1 by detaching from the 2012 RTM server and attaching to a 2012 QU1 server – this is not the recommended route and caused us to suffer the problem the KB2795609 patch addresses.
The problem we still had was follows:
- I have two users a Team Project called ‘BM’ who are in the team called ‘Bad TP’
- Richard (the Team project creator and administrator)
- Fred (a Team Project contributor)
- All is fine for Richard, he can see the team’s product backlog and add items to it.
- Fred can get to the team backlog page in the web client, but cannot see any work items and gets a TF237111 error if they try to add a new work item
- The quick fix was to make Fred a team project administrator, but not a long term solution
- We checked the following rights
- Richard was a member of basically all the groups on the ‘BM’ team project (he was the creator so that was expected), the important ones were [BM\Project administrators, [BM]\contributors and ‘Bad TP’
- Fred was a member of the [BM]\contributors and ‘Bad TP’ team
- The ‘Bad TP’ team had the following permissions
So all these permissions looked OK as you would expect. What I had forgotten was that the team model in TFS 2012 is build around the Area’s hierarchy. This has security permissions too. To check this
- Go to the Admin page for ‘Bad TP’
- Click the “Areas” tab
- Right click the “default area” for the team and select “security”
- We had expect to see some like this
- However there was no entry at all for the Contributors group.
- I added this in and had to explicitly set the four ‘inherited allow‘ permissions to ‘allow’ and everything started to work.
So the problem was that during the problematic upgraded we had managed to strip off all the contributor group entries from area in the existing Team Project. The clue was actually in the TF237111 error as this does mention permissions are the area path.
So now we know we can fix the issue. It should be noted that any new teams created in the team project seem to not get this right applied, so we have to remember to added it when we create a new team.