J’ai remarqué que la gestion des droits dans TFS n’est pas bien compris de tout le monde. Dans la partie sécurité, TFS nous permet de gérer des Team et des groupes et c’est là qu’il y a des confusions.

Les Teams

Même si par défaut il n’y a qu’une seule Team, il peut y en avoir plusieurs par projet. Une Team sert à définir le périmètre d’un utilisateur. On peut par exemple, avoir une Team qui voit la Release 1 du backlog et une autre Team qui voit la Release 2.

Ainsi, on peut restreindre sur les itérations et/ou sur les areas à des utilisateurs en leur définissant une Team.

Tout utilisateurs doit faire partie d’au moins une Team.

Les groupes

Les groupes permettent de définir les droits d’accès d’un utilisateur : Modification du backlog, pouvoir habiliter des utilisateurs sur le projet…

Par défaut, la Team du projet se trouve dans les groupes Contributors et Project Valid Users. Donc tout utilisateur ajouté dans la Team du projet, hérite des autorisations de ces groupes.

Modifier les habilitations d’un utilisateurs

Si un utilisateur a besoin de droits avancés, l’ajouter dans la Team ne suffit pas. Dans ce cas, soit on crée un groupe spécifique qui contiendra les autorisations désirées, soit on ajoute l’utilisateur dans un groupe existant.

Par exemple, un utilisateur qui devra mettre à jour les check in policy d’un projet, Non seulement il doit être dans la Team mais en plus il doit être dans le groupe Build Administrators.

Bonnes pratiques

Il est possible d’ajouter des groupes dans des Team, d’ajouter des Teams dans des groupes, de donner directement des droits à un utilisateurs en cassant l’héritage… Tout cela donne de la flexibilité mais rend illisible la gestion des autorisations.

Mieux vaut créer des groupes spécifiques puis ajouter les utilisateurs dans les groupes plutôt que de casser l’héritage en donnant des droits directement sur un utilisateur.