In a test-driven development environment, QA analysts/engineers usually embedded
into one or multiple Dev team(s). So the management of their TFS permission can
get very labor intensive due to the following requirements:
  • Some users may need to have access to multiple team projects but not all projects so can not use collection level group
  • Some users may have a default team project with full regular permission to it while need read-only access to other projects
  • For those QA groups, you may want to distinguish the permission between team leads (more power) than other team members (less power)
In our case, we also need the grouping strategy to support the 3-party front-end 
tool (Urban Turtle)'s limitation. Thus we have the following goals to achieve:
  • Limit some users the permission to other projects
  • Easy way to make some users (rest of QA) to have access to all projects without re-typing
    them again and again
  • Show some users (Specific QA assign) within Urban Turtle GUI (but not all)
  • Easy to maintain for the future change, i.e., team members, permission, etc.
The solution is to create project-specific groups for their default/major project 
permission and use collection-level groups for the "cross-project" permission 
(could be multiple based on the requirements). However, we still have following 
technical challenges:
  • In TFS, You can not see the user groups from other team projects and you can not see project-level groups from the collection (you can only carry-down the groups from collection to projects but not able to roll-up the groups from projects to collection level).
  • We need the project-specific groups can be re-used by other projects
  • For Urban Turtle, only members of its current level groups will show up in the drop down menu for assigning tasks. (And the PMO really need all necessary users showing up so they can plan and assign tasks on the spot). In other words, members of those rolled-up groups will not show up in Urban Turtle.

To achieve those goals and overcome these challenges, we will have to alter backend database which is not recommended unless you are really comfortable of doing it and recovering it.