Des effets secondaires dus à la suppression de groupes Reader et Contributor dans TFS?

Question

Je souhaite configurer des autorisations TFS pour mieux refléter les responsabilités et les niveaux d'autorisation des différents rôles au sein de mon organisation; Je trouve que les groupes Reader et Contributor par défaut sont trop grossiers pour mes besoins (et trop vaguement nommés).

Pour garder les frais généraux d'entretien au minimum, je suis donc penser à remplacer le Contributeur et les groupes de lecteurs avec mes propres groupes, mais ... est-il un effet secondaire négatif de la suppression de ces deux groupes? Est-ce qu'une partie de TFS compte sur eux étant là?

Answer 1

Cela devrait aller. Les groupes intégrés au niveau du projet sont pour la commodité seulement.

(Cela n'est PAS vrai pour certains groupes de niveau serveur comme TF Valid Users et TF Licensed Users, mais j'oublie également que ces "groupes bien connus" jouent un rôle spécifique dans les opérations internes de TFS. Supprimez-les et le système ne fonctionnera pas, même si vous les recréer exactement comme ils étaient, car les GUID ne correspondront pas.)

Assurez-vous simplement que si vous supprimez le groupe Administrateurs de projet, vous avez toujours l'administrateur privilèges hérités d'un autre groupe (par exemple TF Admins), sinon vous vous retrouverez dans une situation de catch-22. Si vous êtes bloqué par accident, sachez que les administrateurs locaux sur la machine du niveau applicatif sont des «super-administrateurs TFS» qui peuvent contourner tous les contrôles de sécurité et remettre les choses en ordre.

-Edit-

Une chose que vous devez faire est manuellement accorder des autorisations aux nouveaux groupes dans Sharepoint et Reporting Services. Je vous recommande de télécharger le TFS Admin Tool - rend ces tâches beaucoup plus simples.