Team members in the Readers group can create work items!

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) …


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 …


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


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 …


or at the work item area scope …


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 …


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.


Leave a Reply

Your email address will not be published. Required fields are marked *