Team members in the Readers group can create work items!

Team members in the Readers group can create work items!

November 17, 2014 | Scrum, Team Services, TFS 2013

Watch out. This could happen to you and your team.

Let’s assume you have a single team project with three teams (Bacon, Lettuce, and Tomato) …

blt_teams

Next, let’s assume you have Jake, a stakeholder, asking for access to the team project. You don’t want Jake to be able to add, edit, or delete anything, only to read data. Following MSDN’s guidance, you add Jake to the Readers group …

jakereaders

Since Jake only cares about the work that Team Bacon is doing, you add him to that team …

jakebacon

And Bob’s your uncle (translation: unfortunately Jake can now create work items, check-in code, etc.). The reason is that members of team Bacon are de facto Contributors to the team project. The fact that Jake is a member of the Readers group doesn’t matter, because the Readers group does not explicitly DENY any permissions at the team project scope …

readers_permissions

or at the work item area scope …

area_permissions

The Workaround

You could obviously change the “Not set” permissions to “Deny” for the Readers group at the various scopes: team project, area, code, etc. I, Microsoft, and other of my fellow MVPs advise against this because of various performance and troubleshooting reasons.

A better workaround would be to remove Team Bacon from the Contributors group and add it to the Readers group …

bacon_readers_group

Then add the regular Team Bacon members to the Contributors group individually. At this point, Jake (the stakeholder) will have true read-only access as well as only being able to see Team Bacon’s slice of the Product Backlog. The other members of Team Bacon will see no interruption in their day-to-day capabilities.

Add a comment

*Please complete all fields correctly