Référence des autorisations pour Team Foundation Server

Les autorisations déterminent les tâches que les utilisateurs peuvent ou ne peuvent pas réaliser. Pour que les utilisateurs aient accès aux ressources Team Foundation Server (TFS) et aux projets d'équipe, vous devez les ajouter à un projet d'équipe ou à un groupe TFS. Pour une vue d'ensemble de la façon dont TFS gère les membres, les autorisations et l'accès, consultez Gérer les utilisateurs et les groupes dans TFS.

Cette rubrique décrit les autorisations TFS et leurs affectations par défaut à chacun des groupes TFS intégrés. Elle décrit également les outils que vous pouvez utiliser pour définir des autorisations. Il existe trois catégories de groupes intégrés, quatre niveaux d'autorisations et cinq états d'autorisation. L'accès de chaque utilisateur à une tâche fonctionnelle dépend de l'état d'autorisation explicite ou hérité qui lui est assigné ou qui est assigné à un groupe auquel il appartient.

Dans cette rubrique Nouveautés relatives aux autorisations Outils utilisés pour définir les autorisations Groupes TFS intégrés Groupes de niveau serveur Groupes de niveau collection Groupes de niveau projet Autoriser, Refuser, Non défini et autres états d'autorisation Héritage Choses à faire et à ne pas faire lors de la définition d'autorisations Autorisations au niveau du serveur Autorisations au niveau de la collection Autorisations de niveau projet, test et objet Autorisations de niveau projet et test Autorisations au niveau de la build Requête d'élément de travail Étiquetage Niveau zone pour le suivi des éléments de travail Niveau itération pour le suivi des éléments de travail Contrôle de version Team Foundation Référentiel Git Lab Management Gestion des versions

Pour affecter des autorisations aux Produits SharePoint ou à SQL Server Reporting Services, consultez Ajouter des utilisateurs aux projets d'équipe et Accorder des autorisations pour afficher ou créer des rapports dans TFS.

Nouveautés relatives aux autorisations

Le tableau suivant contient les ajouts et modifications apportés au modèle d'autorisations TFS. Ces ajouts et modifications dépendent de la version que vous avez installée sur votre serveur de couche application.

Outils utilisés pour définir les autorisations

Vous pouvez utiliser les outils répertoriés dans le tableau ci-dessous pour définir les autorisations. Différents outils sont utilisés selon que vous définissez les autorisations au niveau d'un serveur, d'une collection ou d'un projet. Vous utilisez Team Web Access (TWA) pour définir la plupart des autorisations permettant aux utilisateurs et aux groupes d'accéder à un projet d'équipe.

Remarques

1. Certaines options d'autorisations auxquelles vous accédez à partir de Team Explorer ouvrent une interface utilisateur dans Team Web Access.

2. Si vous ajoutez Release Management à votre déploiement, vous pouvez gérer les autorisations à l'aide des groupes que vous définissez dans Release Management, TFS, ou Active Directory. Vous pouvez gérer les autorisations via Release Management Client.

Vous pouvez également utiliser l'outil TFSAdmin de CodePlex pour gérer l'appartenance des utilisateurs à des groupes.

Outils en ligne de commande, espaces de noms et noms des autorisations

Quand vous exécutez l'outil en ligne de commande TFSSecurity pour gérer des autorisations, vous spécifiez un espace de noms ainsi que le nom de l'autorisation. Dans les sections qui suivent, l'espace de noms et le nom de commande sont indiqués. Il existe deux groupes d'espaces de noms : collection de projets et serveur. Utilisez la commande TFSSecurity /a pour afficher la liste des espaces de noms. Pour obtenir le jeu d'autorisations que vous pouvez définir sous un espace de noms, utilisez TFSSecurity /a Namespace /collection:CollectionNameURL

Build
BuildAdministration
Chat
Collection
CSS
Discussion Threads
EventSubscription
Git Repositories
Identity
Iteration
Job
Project
ProjectServerAdministration
Registry
Server
ServiceHooks
StrongBox
Tagging
TeamLabSecurity
VersionControlItems
VersionControlPrivileges
WorkItemQueryFolders
WorkItemTrackingAdministration
WorkItemTrackingProvision
Workspaces

Catalog
CollectionManagement
Diagnostic
EventSubscription
Feature Availability
HostingAccount
Identity
Job
Lab
Registry
Server
StrongBox
Warehouse
WebAccess

Groupes TFS intégrés

Lorsque vous installez TFS, quatre groupes sont définis au niveau du serveur. Lorsque vous créez une collection de projets, sept groupes sont créés au niveau de la collection, et pour chaque projet d'équipe que vous créez, six groupes spécifiques au projet d'équipe sont créés. Chacun de ces groupes est associé à un jeu d'autorisations par défaut. Vous ne pouvez pas supprimer des groupes par défaut au niveau du serveur, tels que le groupe Administrateurs Team Foundation.

Remarques :

1. Pour en savoir plus sur les groupes d'utilisateurs valides, accédez la section Qu'est-ce qu'un utilisateur autorisé ? Comment sont remplis les groupes d'utilisateurs autorisés ?.

2. Un groupe équipe est créé avec le nom du projet d'équipe. Par exemple, si vous créez un projet d'équipe nommé « Exemple de code », un groupe équipe sera également créé avec le nom « Équipe Exemple de code ». Vous pouvez renommer cette équipe.

   Par ailleurs, lorsque vous créez de équipes supplémentaires, un groupe équipe est créé pour chaque équipe.

Des autorisations de niveau serveur sont affectées aux groupes de niveau serveur. Des autorisations définies pour la collection, le projet et les objets sont affectées aux groupes de niveau collection. Enfin, des autorisations de niveau projet et de niveau objet sont affectées aux groupes de niveau projet.

Par exemple, l'illustration suivante montre les autorisations affectées au groupe Contributors de niveau projet.

Les autorisations du groupe Project Administrators incluent les autorisations affectées au groupe Contributors plus quelques-unes.

Groupes de niveau serveur

Par défaut, les groupes suivants existent au niveau du serveur pour la couche Application lorsque vous installez TFS.

Groupes de niveau collection

Par défaut, les groupes suivants existent au niveau de la collection lorsque vous configurez une collection.

Groupes de niveau projet

Par défaut, les groupes suivants existent lorsque vous créez un projet d'équipe. Leurs autorisations sont limitées au projet.

Outre ces groupes au niveau du projet, deux groupes au niveau de la collection s'affichent également dans chaque projet dans TFS :

• NomCollectionÉquipeProjet**\Project Collection Administrators**

  Vous ne pouvez pas modifier les autorisations pour ce groupe au niveau de la collection.

• NomCollectionÉquipeProjet**\Project Collection Build Service Accounts**

  Ne supprimez pas ni n'attribuez à l'autorisation Afficher les informations au niveau du projet la valeur Refuser pour ce groupe.

Autoriser, Refuser, Non défini et autres états d'autorisation

TFS utilise un modèle appliquant la permissivité la plus restrictive pour les autorisations de sécurité. Cela signifie que si un utilisateur appartient à deux groupes et que la même autorisation est définie sur Autoriser pour un groupe et sur Refuser pour un autre groupe, Refuser est prioritaire par rapport à Autoriser. Il existe quelques exceptions à cette règle pour les utilisateurs appartenant aux groupes Administrateurs de la collection de projets et Administrateurs de Team Foundation Server.

Vous pouvez spécifier deux états d'autorisation explicites pour les autorisations : Refuser et Autoriser. Il existe par ailleurs trois autres états : Autoriser l'héritage, Interdire l'héritage et Non défini. Non défini est un état Refuser implicite.

Les états d'autorisation suivent les paramètres de priorité suivants :

• L'autorisation Refuser est prioritaire sur tous les autres paramètres d'autorisation, notamment Autoriser. Par exemple, un utilisateur peut appartenir à deux groupes dans un projet. Dans un groupe, l'autorisation Publier les résultats des tests a la valeur Refuser ; dans l'autre groupe, elle a la valeur Autoriser. Le paramètre Refuser est prioritaire et l'utilisateur n'est pas autorisé à publier les résultats des tests.

  Exceptions à cette règle :

  • L'autorisation Refuser n'est pas prioritaire si elle est héritée d'un parent hiérarchique. Les fonctions suivantes prennent en charge le paramètre d'autorisation hiérarchique :

    • Dossiers de contrôle de code source pour le contrôle de version Team Foundation

    • Référentiels Git

    • Nœuds d'itération et de zone pour le suivi des éléments de travail

    • Dossiers de requête et requêtes partagées d'éléments de travail

    Les autorisations explicites définies sur un objet particulier (tel qu'un dossier de contrôle de code source, un référentiel ou un nœud enfant de zone) remplacent celles qui sont héritées des objets parents. Par exemple, l'autorisation Refuser définie pour un dossier de contrôle de code source ne remplace pas une autorisation Autoriser pour l'un de ses sous-dossiers.

  • Quand un utilisateur appartient à un groupe d'administrateurs, tels que les groupes Administrateurs de la collection de projets ou Administrateurs Team Foundation, sauf indication contraire dans la description de l'autorisation.

• Autoriser l'héritage est prioritaire par rapport à Non défini.

Héritage

Lorsque une autorisation est Non défini pour un utilisateur ou à un groupe, l'utilisateur ou le groupe peut être affecté par l'état d'autorisation explicite défini pour les groupes auxquels il appartient étant donné que les autorisations dans TFS sont héritées. Par exemple, lorsque vous examinez les autorisations pour un utilisateur ou un groupe, les options Autoriser et Autoriser l'héritage peuvent toutes deux être définies pour les autorisations. La dernière autorisation est héritée d'un autre groupe auquel l'utilisateur ou le groupe appartient. Dans cet exemple, un utilisateur peut appartenir à un groupe au niveau du projet et à un groupe au niveau de la collection dans un projet. Si l'un de ces groupes a une autorisation définie explicitement sur Autoriser et que l'autre groupe dispose de la même autorisation Non défini, l'utilisateur aura l'autorisation Autoriser l'héritage pour exécuter les actions contrôlées par cette autorisation. L'utilisateur hérite des autorisations des deux groupes, et l'autorisation Autoriser est prioritaire sur l'autorisation Non défini.

Pour comprendre pourquoi une autorisation est héritée, vous pouvez pointer sur le paramètre de l'autorisation et choisir Pourquoi ?. Une nouvelle fenêtre s'ouvre. Elle affiche les informations d'héritage pour cette autorisation.

Certaines boîtes de dialogue Sécurité de niveau objet proposent une option Héritage activé/désactivé. Utilisez cette option afin de désactiver l'héritage pour des dossiers, des requêtes partagées et d'autres objets.

Choses à faire et à ne pas faire lors de l'assignation d'autorisations :

À faire :

• Utilisez des groupes Windows pour la gestion de nombreux utilisateurs.

• Envisagez d'accorder les autorisations Collaboration aux utilisateurs ou aux groupes qui ont besoin de pouvoir créer et partager des requêtes d'élément de travail pour le projet.

• Lors de l'ajout de nombreuses équipes, envisagez de créer un groupe Administrateurs d'équipe dans TFS auquel vous allouez un sous-ensemble des autorisations disponibles pour le groupe Project Administrators.

• Lors de l'ajout d'équipes, réfléchissez aux autorisations que vous voulez affecter aux responsables d'équipe, ScrumMasters et aux autres membres de l'équipe qui peuvent avoir besoin de créer et de modifier des chemins de zone, des chemins d'itération et des requêtes.

À ne pas faire :

• N'ajoutez pas de comptes au groupe Readers que vous avez ajouté au groupe Project Administrators. Si vous le faites, l'état Refuser est affecté à plusieurs autorisations.

• Ne modifiez pas les affectations par défaut d'un groupe d'utilisateurs autorisés. Si vous supprimez ou affectez à l'autorisation Afficher les informations au niveau de l'instance la valeur Refuser pour l'un des groupes d'utilisateurs valides, aucun utilisateur du groupe ne pourra accéder au projet d'équipe, à la collection ou au déploiement, selon le groupe défini.

• N'affectez pas des autorisations notées comme « Affecter uniquement aux comptes de service » à des comptes d'utilisateur.

Autorisations au niveau du serveur

Les autorisations de niveau serveur accordent des autorisations qui peuvent affecter chaque projet et collection du déploiement. Vous pouvez définir les autorisations de niveau serveur à partir de la Console Administration Team Foundation ou à l'aide de l'outil en ligne de commande TFSSecurity.

Vous pouvez définir les autorisations pour les serveurs et groupes de niveau serveur, comme Team Foundation Administrators, et pour les groupes personnalisés de niveau serveur que vous ajoutez.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	SharePoint Web Application Services	Team Foundation Administrators	Team Foundation Service Accounts
Administrer l'entrepôt (remarque 1)	Administrer	Entrepôt	Peut traiter ou modifier des paramètres pour l'entrepôt de données ou le cube SQL Server Analysis à l'aide du service web de contrôle d'entrepôt.
Créer une collection de projets d'équipe	CreateCollection	CollectionManagement	Peut créer et administrer des collections de projets d'équipe.
Supprimer une collection de projets d'équipe (Remarque 2)	DeleteCollection	CollectionManagement	Peut supprimer une collection de projets d'équipes d'un déploiement.
Modifier les informations au niveau de l'instance (remarque 3)	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Serveur	Peut modifier les autorisations de niveau serveur pour les utilisateurs ou groupes TFS, et ajouter ou supprimer des groupes de niveau serveur dans la collection.
Faire des demandes pour le compte de tiers	Impersonate	Serveur	Peut réaliser des opérations au nom d'autres utilisateurs ou services. Affecter uniquement aux comptes de service.
Déclencher des événements	TRIGGER_EVENT	Serveur	Peut déclencher des événements d'alerte TFS. Affecter uniquement aux comptes de service et aux membres du groupe Team Foundation Administrators.
Utiliser les fonctionnalités d'accès total Web Access (remarque 4)	FullAccess	Serveur	Peut utiliser toutes les fonctionnalités TWA.
Afficher les informations au niveau de l'instance (remarque 5)	GENERIC_READ	Serveur	Peut afficher les membres du groupe de niveau serveur et les autorisations de ces utilisateurs.

Remarques :

1. Des autorisations supplémentaires peuvent être nécessaires pour traiter ou reconstruire entièrement l'entrepôt de données et le cube Analysis.

2. Le fait de supprimer une collection de projets d'équipe ne supprime pas la base de données de collections de SQL Server.

3. L'autorisation Modifier les informations au niveau de l'instance permet d'effectuer les taches suivantes pour tous les projets d'équipe définis dans toutes les collections de projets définies pour l'instance :

   • Ajouter et administrer des équipes et toutes les fonctionnalités liées aux équipes

   • Créer et modifier des zones et des itérations

   • Modifier les stratégies d'archivage

   • Modifier les requêtes d'éléments de travail partagées

   • Modifier les listes de contrôle d'accès d'autorisations au niveau du projet et au niveau de la collection

   • Créer et modifier des listes globales

   • Modifier des abonnements à des événements (messagerie électronique ou SOAP).

   Lorsqu'elle est définie via les menus, l'autorisation Modifier les informations au niveau de l'instance permet également de manière implicite à l'utilisateur de modifier des autorisations de contrôle de version. Pour accorder toutes ces autorisations depuis une invite de commandes, vous devez utiliser la commande tf.exe Permission pour accorder les autorisations AdminConfiguration et AdminConnections en plus de GENERIC_WRITE.

4. Si l'autorisation Utiliser les fonctionnalités d'accès total Web Access a la valeur Refuser, l'utilisateur verra uniquement les fonctionnalités autorisées pour le groupe Limité (voir Modifier les niveaux d'accès). Une autorisation ayant la valeur Refuser substituera toute autorisation implicite, même pour les comptes qui sont membres de groupes d'administration, par exemple Team Foundation Administrators.

5. L'autorisation Afficher les informations au niveau de l'instance est également assignée au groupe Team Foundation Valid Users.

Autorisations au niveau de la collection

Les autorisations de niveau collection donnent accès aux tâches affectant une collection, que vous pouvez définir pour les utilisateurs et groupes suivants :

• Les utilisateurs et les groupes au niveau de la collection tels que le groupe Project Collection Administrators

• Groupes de niveau projet que vous ajoutez à une collection.

• Groupes personnalisés que vous ajoutez à une collection.

Vous pouvez définir des autorisations de niveau collection à partir de la page d'administration de TWA ou de la Console Administration Team Foundation, ou encore à l'aide de l'outil en ligne de commande TFSSecurity ou de l'outil en ligne de commande tf. Toutes les autorisations se limitent à la collection spécifique pour laquelle elles sont définies.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Project Collection Service Accounts	Project Collection Build Service Accounts	Project Collection Build Administrators	Administrateurs de collections de projets (Remarque 1)
Administrer les autorisations de ressources de builds	AdministerBuildResourcePermissions	BuildAdministration	Peut modifier les autorisations pour les ressources de build.
Administrer l'intégration Project Server	Administrer Project Server	ProjectServerAdministration	Peut configurer l'intégration de TFS et Project Server pour permettre la synchronisation de données entre les deux produits serveur.
Administrer les modifications réservées	AdminShelvesets tf: AdminShelvesets	VersionControlPrivileges	Peut supprimer des jeux de réservations créés par d'autres utilisateurs.
Administrer les espaces de travail	AdminWorkspaces tf: AdminWorkspaces	VersionControlPrivileges	Peut créer des espaces de travail pour les autres utilisateurs et supprimer les espaces de travail créés par d'autres utilisateurs.
Modifier les paramètres de suivi	DIAGNOSTIC_TRACE	Collection	Peut modifier les paramètres de suivi afin de collecter des informations de diagnostic plus détaillées sur les services web TFS.
Créer un espace de travail (remarque 2)	tf: CreateWorkspace	VersionControlPrivileges	Peut créer un espace de travail de contrôle de version.
Créer des projets (remarque 3)	CREATE_PROJECTS	Collection	Peut créer des projets dans la collection de projets d'équipe.
Supprimer un projet d'équipe (remarque 4)	Supprimer	Project	Peut supprimer des projets d'équipe.
Modifier les informations au niveau de la collection (remarque 5)	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Collection VersionControlPrivileges	Peut ajouter des utilisateurs et des groupes, et modifier les autorisations de niveau collection pour les utilisateurs et les groupes.
Faire des demandes pour le compte de tiers	Impersonate	Serveur	Peut réaliser des opérations au nom d'autres utilisateurs ou services. Affecter uniquement aux comptes de service.
Gérer les ressources de build	ManageBuildResources	BuildAdministration	Peut gérer les ordinateurs, agents et contrôleurs de build.
Gérer le modèle de processus	MANAGE_TEMPLATE	Collection	Peut télécharger, créer, modifier et transférer des modèles de processus.
Gérer les contrôleurs de test	MANAGE_TEST_CONTROLLERS	Collection	Peut enregistrer et annuler l'enregistrement de contrôleurs de test.
Déclencher des événements (remarque 6)	TRIGGER_EVENT	Collection	Peut déclencher des événements d'alerte de projet dans la collection. Affecter uniquement aux comptes de service.
Utiliser les ressources de build	UseBuildResources	BuildAdministration	Peut réserver et allouer des agents de build. Affecter uniquement aux comptes de service pour les services de build.
Afficher les ressources de build	ViewBuildResources	BuildAdministration	Peut consulter mais ne pas utiliser, les contrôleurs de build et agents de build configurés pour la collection.
Afficher les informations au niveau de la collection	GENERIC_READ	Collection	Peut afficher les membres du groupe de niveau collection et les autorisations.
Afficher les informations de synchronisation système	SYNCHRONIZE_READ	Collection	Peut appeler les interfaces de programmation d'applications de synchronisation. Affecter uniquement aux comptes de service.

Remarques :

1. Par ailleurs, les autorisations par défaut suivantes sont affectées aux groupes TFS :

   • Groupe Utilisateurs autorisés de la collection de projets : Créer un espace de travail, Afficher les ressources de build et Afficher les informations au niveau de la collection.

   • Comptes de service proxy de la collection de projets : Créer un espace de travail, Afficher les ressources de build et Afficher les informations au niveau de la collection.

   • Comptes de service test de la collection de projets : Créer un espace de travail, Gérer les contrôleurs de test, Afficher les ressources de build et Afficher les informations au niveau de la collection.

2. L'autorisation Créer un espace de travail est accordée à tous les utilisateurs qui sont membres du groupe Utilisateurs autorisés de la collection de projets.

3. Des autorisations supplémentaires peuvent être requises en fonction de votre déploiement. Par ailleurs, vous devez exécuter Visual Studio ou Team Explorer en tant qu'administrateur pour réaliser l'Assistant Nouveau projet d'équipe.

4. La suppression d'un projet d'équipe supprimera toutes les données associées au projet. Vous ne pouvez pas annuler la suppression d'un projet d'équipe sauf en restaurant la collection à un point avant la suppression du projet.

5. L'autorisation Modifier les informations au niveau de la collection permet d'effectuer les taches suivantes pour tous les projets d'équipe définis dans une collection :

   • Ajouter et administrer des équipes et toutes les fonctionnalités liées aux équipes

   • Créer et modifier des zones et des itérations

   • Modifier les stratégies d'archivage

   • Modifier les requêtes d'éléments de travail partagées

   • Modifier les listes de contrôle d'accès d'autorisations au niveau du projet et au niveau de la collection

   • Créer et modifier des listes globales

   • Modifier des abonnements à des événements (messagerie électronique ou SOAP) sur des événements au niveau du projet ou de la collection.

   Lorsque vous définissez Modifier les informations au niveau de la collection sur Autoriser par le biais de TWA, les utilisateurs peuvent ajouter ou supprimer des groupes TFS de niveau collection et ces utilisateurs sont implicitement autorisés à modifier les autorisations de contrôle de version. Pour accorder toutes ces autorisations depuis une invite de commandes, vous devez utiliser la commande tf.exe Permission pour accorder les autorisations AdminConfiguration et AdminConnections en plus de GENERIC_WRITE.

6. Les utilisateurs disposant de cette autorisation ne peuvent pas supprimer les groupes de niveau collection intégrés comme Administrateurs de la collection de projets.

7. L'ajout de cette autorisation à d'autres utilisateurs peut susciter d'éventuelles attaques par déni de service.

Autorisations de niveau projet, test et objet

Les autorisations au niveau du projet sont spécifiques aux utilisateurs et aux groupes d'un projet unique. Au sein d'un projet, vous pouvez définir des autorisations sur les objets créés pour ce projet, comme les zones, les itérations, les dossiers de contrôle du code source, les requêtes et les dossiers de requêtes, et les définitions de build. Vous pouvez définir des autorisations de niveau projet et objet pour les utilisateurs et les groupes que vous ajoutez à un projet d'équipe ou une collection.

De nombreuses autorisations par défaut sont affectées aux groupes de niveau collection et de niveau projet intégrés suivants :

• Groupes de niveau projet : Builders, Contributors, Project Administrators et Readers

• Groupes de niveau collection : Administrateurs de la collection de projets, Comptes de service de build de la collection de projets, Comptes de service proxy de la collection de projets et Comptes de service test de la collection de projets

Autorisations de niveau projet et test

Vous pouvez définir des autorisations au niveau du projet à partir de la page d'administration TWA du projet ou à l'aide de l'outil en ligne de commande TFSSecurity. Toutes les autorisations de niveau projet autorisent les utilisateurs pour le projet d'équipe spécifique pour lequel elles sont définies.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Administrateurs de build, Collaborateurs et Équipes	Project Administrators (remarque 1)
Créer une définition de balise	Créer	Étiquetage	Peut ajouter des balises via un formulaire d'élément de travail.
Créer des séries de tests	PUBLISH_TEST_RESULTS	Project	Peut ajouter et supprimer des résultats de test et ajouter ou modifier des séries de tests.
Supprimer le projet d'équipe	SUPPR	Project	Peut supprimer le projet d'équipe de TFS.
Supprimer des séries de tests	DELETE_TEST_RESULTS	Project	Peut supprimer un test planifié.
Modifier les informations au niveau du projet (remarque 2)	GENERIC_WRITE	Project	Peut modifier les autorisations de niveau projet pour les utilisateurs et les groupes.
Gérer des configurations de test	MANAGE_TEST_CONFIGURATIONS	Project	Peut créer et supprimer des configurations de test.
Gérer les environnements de test	MANAGE_TEST_ENVIRONMENTS	Project	Les utilisateurs disposant de cette autorisation peuvent créer et supprimer des environnements de test.
Afficher les informations au niveau du projet	GENERIC_READ	Project	Peut afficher les membres du groupe de niveau projet et les autorisations.
Afficher les séries de tests	VIEW_TEST_RESULTS	Project	Peut afficher les plans de test dans le chemin de zone du projet d'équipe.

Remarques :

1. Par ailleurs, les autorisations par défaut suivantes sont affectées aux groupes TFS :

   • Readers : Créer la définition de balise, Afficher les informations au niveau du projet et Afficher des séries de tests.

   • Administrateurs de la collection de projets : mêmes autorisations que Project Administrators, sauf pour Supprimer des séries de tests.

   • Administrateurs de build de la collection de projets : mêmes autorisations que Project Administrators, sauf pour Supprimer des séries de tests.

   • Comptes de service de build de la collection de projets : Créer des séries de tests, Gérer les configurations de test, Gérer les environnements de test, Afficher les informations au niveau du projet, Afficher des séries de tests.

   • Comptes de service de test de la collection de projets : Créer des séries de tests, Gérer les configurations de test, Gérer les environnements de test, Afficher les informations au niveau du projet.

2. L'autorisation Modifier les informations au niveau du projet permet d'effectuer les taches suivantes pour le projet d'équipe :

   • Ajouter et administrer des équipes et toutes les fonctionnalités liées aux équipes

   • Créer et modifier des zones et des itérations

   • Modifier les stratégies d'archivage

   • Modifier les requêtes d'éléments de travail partagées

   • Modifier les listes de contrôle d'accès de niveau projet

   • Créer et modifier des listes globales

   • Modifier des abonnements à des événements (messagerie électronique ou SOAP) sur des événements au niveau du projet.

Autorisations au niveau de la build

Vous pouvez définir des autorisations au niveau de la build pour toutes les build ou pour une définition de build à partir du menu contextuel de la définition de build dans TWA ou Team Explorer, ou à l'aide de l'outil en ligne de commande TFSSecurity.

Nom de l'autorisation (IU)	Action TFSSecurity	Espace de noms TFSSecurity	Description	Contributors	Auteurs ou générateurs de la définition de build	Administrateurs de build	Project Administrators (remarque 1)
Administrer les autorisations de builds	AdministerBuildPermissions	Build	Peut administrer les autorisations de build pour les autres utilisateurs.
Supprimer la définition de build	DeleteBuildDefinition	Build	Peut supprimer des définitions de build pour ce projet.
Supprimer les builds	DeleteBuilds	Build	Peut supprimer une build terminée.
Détruire les builds	DestroyBuilds	Build	Peut supprimer de manière définitive une build terminée.
Modifier la définition de build (Remarque 2)	EditBuildDefinition	Build	Peut créer ou modifier des définitions de build pour ce projet.
Modifier la qualité de build	EditBuildQuality	Build	Peut ajouter des informations sur la qualité de la build via Team Explorer ou Team Web Access.
Gérer les qualités de build	ManageBuildQualities	Build	Peut ajouter ou supprimer des qualités de build.
Gérer la file d'attente de builds	ManageBuildQueue	Build	Peut annuler, redéfinir la priorité ou retarder des builds en file d'attente.
Remplacer la validation de l'archivage par build (remarque 3)	OverrideBuildCheckInValidation	Build	Peut valider un ensemble de modifications qui affecte une définition de build contrôlée sans que cela déclenche par le système la réservation et la génération en premier lieu des modifications le concernant.
Mettre les builds en file d'attente	QueueBuilds	Build	Peut mettre une build en file d'attente via l'interface de Team Foundation Build ou à une invite de commandes. Ils peuvent également arrêter les builds qu'ils ont mises en file d'attente.
Conserver indéfiniment	RetainIndefinitely	Build	Peut marquer une build de sorte qu'elle ne soit pas supprimée automatiquement par toute stratégie de rétention applicable.
Arrêter les builds	StopBuilds	Build	Peut arrêter une build en cours, y compris les builds mises en file d'attente et démarrées par un autre utilisateur.
Mettre à jour les informations de build	UpdateBuildInformation	Build	Peut ajouter des nœuds d'informations de build au système et ajouter des informations sur la qualité d'une build. Affecter uniquement aux comptes de service.
Afficher la définition de build	ViewBuildDefinition	Build	Peut afficher les définitions de build qui ont été créées pour le projet d'équipe.
Afficher les builds	ViewBuilds	Build	Peut afficher les builds mises en file d'attente et terminées pour ce projet d'équipe.

Remarques :

1. De plus, les assignations par défaut suivantes sont effectuées pour ces groupes intégrés :

   • Readers : Afficher la définition de build et Afficher les builds.

   • Administrateurs de la collection de projets : toutes les autorisations à l'exception de Mettre à jour les informations de build.

   • Administrateurs de build de la collection de projets : toutes les autorisations à l'exception de Remplacer la validation de l'archivage par build et Mettre à jour les informations de build.

   • Comptes de service de build de la collection de projets : Modifier la qualité de build, Gérer la file d'attente de builds, Mettre à jour les informations de build, Remplacer la validation de l'archivage par build, Mettre les builds en file d'attente, Afficher les définitions de build et Afficher les builds.

   • Comptes de service de test de la collection de projets : Mettre à jour les informations de build, Afficher les définitions de build et Afficher les builds.

2. Vous désactivez l'héritage pour une définition de build quand vous souhaitez contrôler les autorisations pour des définitions de builds spécifiques.

   Quand l'héritage est activé, la définition de build respecte les autorisations de builds définies au niveau du projet pour un groupe ou un utilisateur. Par exemple, pour un groupe Responsables de builds personnalisé, les autorisations sont définies de façon à mettre manuellement en file d'attente une build pour le projet Fabrikam. Toute définition de build avec l'héritage activé pour le projet Fabrikam autoriserait un membre du groupe Responsable de builds à mettre manuellement en file d'attente une build.

   Toutefois, en désactivant l'héritage pour le projet, vous pouvez définir des autorisations qui autorisent uniquement les Administrateurs de projet à mettre manuellement en file d'attente une build pour une définition de build spécifique. Vous pourriez alors définir des autorisations spécifiquement pour cette définition de build.

3. Affectez l'autorisation Remplacer la validation de l'archivage par build uniquement aux comptes de service pour les services de build et aux administrateurs de build chargés de la qualité du code. Pour plus d'informations, consultez Archiver des modifications en attente contrôlées par une build d'archivage contrôlé.

Autorisations de requêtes d'élément de travail

Vous pouvez définir les autorisations de requêtes d'élément de travail à partir du menu contextuel de Requêtes partagées dans TWA ou Team Explorer ou à l'aide de l'outil en ligne de commande TFSSecurity. Toutes les autorisations se limitent à la requête ou au dossier de requête spécifique pour lequel elles sont définies.

Envisagez d'accorder les autorisations Collaboration aux utilisateurs ou aux groupes qui ont besoin de pouvoir créer et partager des requêtes d'élément de travail pour le projet. Pour créer des graphiques de requêtes vous avez besoin d'un accès Avancé.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Readers, Contributors, Administrateurs de build	Créateur, Propriétaires, Project Administrators, Administrateurs de la collection de projets
Collaboration	COLLABORATION	WorkItemQueryFolders	Peut afficher et modifier cette requête ou ce dossier de requête.
Supprimer	SUPPR	WorkItemQueryFolders	Peut supprimer une requête ou un dossier de requête et son contenu.
Gérer les autorisations	Gérer les autorisations		Peut gérer les autorisations pour cette requête ou ce dossier de requête.
Lecture	READ	WorkItemQueryFolders	Peut afficher et utiliser la ou les requêtes contenues dans un dossier, mais ne peut pas modifier la requête ou le contenu du dossier de requête.
	FullControl	WorkItemQueryFolders	Peut afficher, modifier, supprimer et gérer les autorisations pour une requête ou un dossier de requête et son contenu.

Balisage des autorisations

Les balises permettent de rapidement regrouper ou classer les éléments de travail. Les autorisations de balisage sont disponibles dans les déploiements locaux de TFS avec TFS 2013.2 ou version ultérieure installé. Vous pouvez définir l'autorisation Créer la définition de balise à partir de la page de sécurité d'administration de TWA. Pour définir toutes les autorisations restantes, utilisez l'outil en ligne de commande TFSSecurity.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Readers	Contributors	Project Administrators (remarque 1)
Créer la définition de balise (remarque 2)	CREATE	Étiquetage	Peut créer des balises et les appliquer aux éléments de travail. Les utilisateurs qui n'ont pas cette autorisation peuvent uniquement choisir dans le jeu existant de balises pour le projet de l'équipe.
Supprimer la définition de balise (remarques 3 et 4)	SUPPR	Étiquetage	Peut supprimer une balise de la liste des balises disponibles pour ce projet.
Énumérer les définitions de balises (Remarques 4 et 5)	ENUMERATE	Étiquetage	Peut afficher la liste des balises disponibles pour l'élément de travail dans le projet d'équipe. Les utilisateurs qui n'ont pas cette autorisation n'ont pas de liste de balises disponibles à partir de laquelle choisir le formulaire d'élément de travail ou l'éditeur de requête.
Mettre à jour la définition de balise (remarque 4)	UPDATE	Étiquetage	Peut renommer une balise à l'aide de l'API REST.

Remarques :

1. De plus, toutes les autorisations de balisage sont assignées de manière explicite au groupe Comptes de service de la collection de projets.

2. Les Lecteurs et Collaborateurs héritent de l'autorisation Créer la définition de balise, car elle est définie de manière explicite sur Autoriser pour le groupe Utilisateurs valides du projet.

   Bien que l'autorisation Créer une définition de balise s'affiche dans les paramètres de sécurité au niveau du projet d'équipe, les autorisations de balises sont en fait des autorisations au niveau de la collection qui sont étendues au projet lorsqu'elles apparaissent dans l'interface utilisateur. Pour limiter les autorisations de balisage à un seul projet d'équipe à l'aide de la commande TFSSecurity, vous devez fournir le GUID du projet dans la syntaxe de la commande. Sinon, la modification s'applique à la collection de projets d'équipe entière. Gardez cela à l'esprit lors de la modification ou de la définition de ces autorisations.

3. Aucune interface utilisateur n'est prise en charge pour la suppression d'une balise. Pour supprimer une balise, supprimez les affectations associées à cette balise. TFS supprime automatiquement les balises non affectées après 3 jours de non-utilisation.

4. N'apparaît pas dans l'interface utilisateur ; peut uniquement être définie à l'aide de la commande TFSSecurity.

5. L'autorisation Afficher les informations au niveau du projet définie sur Autoriser pour les Lecteurs et les Collaborateurs autorise de manière implicite les utilisateurs de ces groupes à afficher les balises existantes (autorisation Énumérer les définitions de balises).

Autorisations au niveau de la zone pour le suivi des éléments de travail

Les autorisations de niveau zone accordent ou refusent l'accès aux éléments de travail définis pour un projet en fonction de leur emplacement dans leur arborescence de zone.

Vous pouvez définir les autorisations de niveau zone à partir de la page d'administration de TWA relative aux zones ou à l'aide de l'outil en ligne de commande TFSSecurity. Toutes les autorisations se limitent au chemin de zone spécifique pour lequel elles sont définies.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Contributors	Administrateurs de build	Comptes de service de build de la collection de projets (Remarque 1)
Créer des nœuds enfants (remarque 2)	CREATE_CHILDREN	CSS	Peut créer de nœuds de zone. Les utilisateurs qui ont cette autorisation et l'autorisation Modifier ce nœud peuvent déplacer ou réorganiser des nœuds de zone enfants.
Supprimer ce nœud (remarque 2)	SUPPR	CSS	Les utilisateurs qui ont cette autorisation et l'autorisation Modifier ce nœud pour un autre nœud peuvent supprimer des nœuds de zone et reclasser des éléments de travail existants à partir du nœud supprimé. Si le nœud supprimé a des nœuds enfants, ces nœuds sont également supprimés.
Modifier ce nœud (remarque 2)	GENERIC_WRITE	CSS	Peut définir les autorisations pour ce nœud et renommer les nœuds de zone.
Modifier les éléments de travail dans ce nœud (remarque 3)	WORK_ITEM_WRITE	CSS	Peut modifier les éléments de travail dans ce nœud de zone.
Gérer les plans de test (remarque 4)	MANAGE_TEST_PLANS	CSS	Peut modifier les propriétés de plan de test comme les paramètres de build et de test.
Gérer les suites de tests (remarque 4)	MANAGE_TEST_SUITES	CSS	Peut créer et supprimer des suites de tests, ajouter et supprimer des cas de test dans des suites de tests, modifier les configurations de test associées à des suites de tests et modifier la hiérarchie des suites (déplacer une suite de tests).
Afficher les autorisations pour ce nœud	GENERIC_READ	CSS	Peut afficher les paramètres de sécurité de ce nœud.
Afficher les éléments de travail dans ce nœud (remarque 5)	WORK_ITEM_READ	CSS	Peut afficher, mais pas modifier, les éléments de travail dans ce nœud de zone.

Remarques :

1. De plus, les assignations par défaut suivantes sont effectuées pour ces groupes intégrés :

   • Readers : autorisations Afficher pour ce nœud et autorisations Affichage uniquement.

   • Comptes de service test de la collection de projets : autorisations Affichage uniquement.

   • Administrateurs Team Foundation, Administrateurs de collections de projets et Administrateurs de projet : toutes les autorisations CSS. Tout utilisateur ou groupe qui dispose de l'autorisation Modifier les informations au niveau de l'instance, Modifier les informations au niveau de la collection ou Modifier les informations au niveau du projet peut créer et gérer des nœuds de zone.

   • Les membres des groupes Utilisateurs autorisés de la collection de projets et Utilisateurs valides du projet ou tout utilisateur ou groupe disposant de l'autorisation Afficher les informations au niveau de la collection ou Afficher les informations au niveau du projet peut afficher les autorisations de n'importe quel nœud de zone.

2. Envisagez d'ajouter cette autorisation à tout utilisateur ou groupe ajouté manuellement pour lequel vous pourriez avoir besoin de supprimer, d'ajouter ou de renommer des nœuds de zone.

3. Envisagez d'ajouter cette autorisation à tout utilisateur ou groupe ajouté manuellement pour lequel vous pourriez avoir besoin de modifier des éléments de travail sous ce nœud de zone.

4. L'autorisation Gérer les suites de tests a été ajoutée avec la mise à jour TFS 2013.3. Envisagez d'ajouter ces autorisations à tout utilisateur ou groupe ajouté manuellement pour lequel vous pourriez avoir besoin de gérer les plans de test ou les suites de tests sous ce nœud de zone.

5. Si dans ce nœud, vous définissez l'autorisation Afficher les éléments de travail sur Refuser, l'utilisateur ne sera pas en mesure d'afficher les éléments de travail dans ce nœud de zone. Une autorisation ayant la valeur Refuser substituera toute autorisation implicite, même pour les comptes qui sont membres de groupes d'administration, par exemple Team Foundation Administrators.

Autorisations au niveau de l'itération pour le suivi des éléments de travail

Les autorisations de niveau itération accordent ou refusent l'accès pour la création et la gestion des chemins d'itération.

Vous pouvez définir les autorisations de niveau itération pour les utilisateurs et les groupes que vous ajoutez au projet d'équipe ou à la collection à l'aide de la page d'administration de TWA pour les itérations ou de l'outil en ligne de commande TFSSecurity. Toutes les autorisations se limitent au chemin d'itération spécifique pour lequel elles sont définies.

Certaines opérations de suivi des éléments de travail requièrent plusieurs autorisations. Par exemple, vous avez besoin de plusieurs autorisations pour supprimer un nœud.

Envisagez d'accorder aux administrateurs d'équipe, ScrumMasters ou responsables d'équipe les autorisations de créer, modifier ou supprimer des nœuds.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Project Administrators (remarque 1)
Créer des nœuds enfants (remarque 2)	CREATE_CHILDREN	Itération	Peut créer de nœuds d'itération. Les utilisateurs qui ont cette autorisation et l'autorisation Modifier ce nœud peuvent déplacer ou réorganiser des nœuds d'itération enfants.
Supprimer ce nœud (remarque 2)	SUPPR	Itération	Les utilisateurs qui ont cette autorisation et l'autorisation Modifier ce nœud pour un autre nœud peuvent supprimer des nœuds d'itération et reclasser des éléments de travail existants à partir du nœud supprimé. Si le nœud supprimé a des nœuds enfants, ces nœuds sont également supprimés.
Modifier ce nœud (remarque 2)	GENERIC_WRITE	Itération	Peut définir les autorisations pour ce nœud et renommer les nœuds d'itération.
Afficher les autorisations pour ce nœud (Remarque 3)	GENERIC_READ	Itération	Peut afficher les paramètres de sécurité de ce nœud.

Remarques :

1. toutes les autorisations d'itération sont accordées aux Administrateurs Team Foundation et aux Administrateurs de collections de projets. Tout utilisateur ou groupe qui dispose de l'autorisation Modifier les informations au niveau de l'instance, Modifier les informations au niveau de la collection ou Modifier les informations au niveau du projet peut créer et gérer des nœuds d'itération.

2. Vous pouvez ajouter cette autorisation à un utilisateur ou à un groupe ajouté manuellement susceptible de devoir supprimer, ajouter ou renommer des nœuds d'itération.

3. Les membres des groupes Utilisateurs autorisés de la collection de projets et Utilisateurs valides du projet ou tout utilisateur ou groupe disposant de l'autorisation Afficher les informations au niveau de la collection ou Afficher les informations au niveau du projet peut afficher les autorisations de n'importe quel nœud d'itération.

Autorisations de contrôle de version Team Foundation (TFVC)

Vous pouvez définir des autorisations sur des dossiers et fichiers de code source TFVC à partir du menu contextuel de la définition de dossier ou de fichier dans TWA ou Team Explorer, ou à l'aide de l'outil en ligne de commande tf permission. Ces autorisations apparaissent uniquement pour un projet d'équipe configuré pour utiliser TFVC comme système de contrôle du code source.

Dans les autorisations de contrôle de version, un refus explicite est prioritaire sur les autorisations du groupe d'administrateurs.

Nom de l'autorisation	Action TFSSecurity et tf perm	Espace de noms TFSSecurity	Description	Contributors	Administrateurs de build	Project Collection Build Service Accounts	Project Administrators (remarque 1)
Administrer les étiquettes	tf: LabelOther	VersionControlItems	Peut modifier ou supprimer des étiquettes créées par un autre utilisateur.
Archiver (voir remarque 2)	tf: Checkin	VersionControlItems	Peut archiver des éléments et réviser tout commentaire sur un ensemble de modifications validé. Les modifications en attente sont validées lors de l'archivage.
Archiver les modifications des autres utilisateurs	tf: CheckinOther	VersionControlItems	Peut archiver les modifications qui ont été apportées par d'autres utilisateurs. Les modifications en attente sont validées lors de l'archivage.
Extraire (voir remarque 2)	tf: PendChange	VersionControlItems	Peut extraire ou appliquer une modification en attente aux éléments d'un dossier. Les exemples de modification en attente incluent l'ajout, la modification, le changement de nom, la suppression, la restauration, le branchement et la fusion d'un fichier. Les modifications en attente doivent être archivées, les utilisateurs ont donc également besoin de l'autorisation Archiver pour partager leurs modifications avec l'équipe.
Étiquette	tf: Label	VersionControlItems	Peut appliquer une étiquette aux éléments.
Verrouiller	tf: Lock	VersionControlItems	Peut verrouiller et déverrouiller des dossiers et des fichiers.
Gérer la branche	tf: ManageBranch	VersionControlItems	Peut convertir en branche tout dossier sous ce chemin et effectuer les actions suivantes sur la branche : modifier ses propriétés, lui affecter un nouveau parent et la convertir en dossier. Les utilisateurs qui ont cette autorisation peuvent ramifier cette branche seulement s'ils possèdent également l'autorisation Fusionner pour le chemin cible. Les utilisateurs ne peuvent pas créer de branches à partir d'une branche pour laquelle ils n'ont pas l'autorisation Gérer la branche.
Gérer les autorisations (remarque 3)	tf: AdminProjectRights	VersionControlItems	Peut gérer les autorisations d'autres utilisateurs pour les dossiers et les fichiers dans le contrôle de version.
Fusionner (remarque 4)	tf: Merge	VersionControlItems	Peut fusionner les modifications dans ce chemin.
Lecture	tf: Read	VersionControlItems	Pour lire le contenu d'un fichier ou d'un dossier. Si un utilisateur possède les autorisations Lire pour un dossier, il peut consulter le contenu du dossier et les propriétés des fichiers, même s'il n'a pas d'autorisation pour ouvrir les fichiers.
Réviser les modifications des autres utilisateurs (remarque 5)	tf: ReviseOther	VersionControlItems	Peut modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.
Annuler les modifications des autres utilisateurs Fusionner (remarque 5)	tf: UndoOther	VersionControlItems	Peut annuler une modification en attente apportée par un autre utilisateur.
Déverrouiller les modifications des autres utilisateurs (remarque 5)	tf: UnlockOther	VersionControlItems	Peut déverrouiller les fichiers verrouillés par d'autres utilisateurs.

Remarques :

1. Par ailleurs, toutes les autorisations sont définies sur Autoriser l'héritage pour les groupes Administrateurs de la collection de projets et Comptes de service de la collection de projets.

   Le groupe Readers dispose d'autorisations limitées à l'affichage : Lire.

2. Envisagez d'ajouter ces autorisations à tout utilisateur ou groupe ajouté manuellement qui collabore au développement du projet, de même qu'à tout utilisateur qui doit être en mesure d'archiver et d'extraire des modifications, d'apporter des modifications en attente aux éléments d'un dossier ou de réviser tout commentaire sur un ensemble de modifications validé.

3. Envisagez d'ajouter cette autorisation à tout utilisateur ou groupe ajouté manuellement qui collabore au développement du projet et qui doit être en mesure de créer des branches privées, sauf si le projet est soumis à des pratiques de développement plus restrictives.

4. Envisagez d'ajouter cette autorisation à tout utilisateur ou groupe ajouté manuellement qui collabore au développement du projet et qui doit être en mesure de fusionner des fichiers source, sauf si le projet est soumis à des pratiques de développement plus restrictives.

5. Envisagez d'ajouter cette autorisation à tout utilisateur ou groupe ajouté manuellement chargé de la gestion ou de la surveillance du projet et qui devra modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.

Autorisations de référentiel Git

Vous pouvez définir des autorisations sur un projet, un référentiel ou une branche Git à partir du menu contextuel ou de la page d'administration dans TWA, ou bien à l'aide de l'outil en ligne de commande TFSSecurity. Ces autorisations apparaissent uniquement pour un projet d'équipe configuré pour utiliser Git comme système de contrôle du code source.

Vous pouvez définir toutes les autorisations pour un projet ou référentiel. Vous pouvez définir les autorisations Administrer, Collaboration et Réécrire et détruire l'historique (opération push forcée) pour une branche. Les référentiels et les branches héritent les autorisations des affectations effectuées au niveau du projet.

Par défaut, les groupes Lecteurs au niveau du projet et au niveau de la collection ne disposent que d'autorisations de lecture.

Nom de l'autorisation	Action TFSSecurity	Espace de noms TFSSecurity	Description	Contributors	Administrateurs de build	Project Administrators (remarque 1)
Administrer (remarque 2)	Administrer	GitRepositories	Peut renommer le référentiel, ajouter des référentiels supplémentaires, vérifier la base de données et définir des autorisations pour la branche. Les utilisateurs qui ont cette autorisation peuvent supprimer le référentiel, à condition d'avoir également l'autorisation Forcer. Au niveau de la branche, peut définir des autorisations pour la branche et supprimer la branche.
Création de branche	CreateBranch	GitRepositories	Peut publier des branches dans le référentiel. L'absence de cette autorisation n'empêche pas les utilisateurs de créer des branches dans leur référentiel local ; elle les empêche simplement de publier les branches locales sur le serveur. Lorsqu'un utilisateur crée une branche sur le serveur, il dispose par défaut des autorisations Administrer, Collaboration et Forcer pour cette branche.
Collaboration	GenericContribute	GitRepositories	Peut effectuer une transmission de type push des modifications au référentiel. Au niveau de la branche, peut effectuer une transmission de type push des modifications à la branche.
Gestion des notes	ManageNote	GitRepositories	Peut effectuer une transmission de type push et modifier les remarques Git dans le référentiel. Peut également supprimer les remarques des éléments si l'utilisateur dispose également de l'autorisation Forcer. Pour plus d'informations sur les remarques, consultez http://git-scm.com/2010/08/25/notes.html.
Lecture	GenericRead	GitRepositories	Peut cloner, récupérer, extraire et explorer le contenu du référentiel, mais ne peut émettre aucune modification effectuée sur le référentiel.
Réécrire et détruire l'historique (opération push forcée)	ForcePush	GitRepositories	Peut forcer une mise à jour, laquelle peut écraser ou ignorer les validations de n'importe quel utilisateur. La suppression de validations modifie l'historique. Sans cette autorisation, les utilisateurs ne peuvent pas ignorer leurs propres modifications. L'autorisation Réécrire et détruire l'historique est également requise pour supprimer une branche. Étant donné que l'autorisation Réécrire et détruire l'historique permet aux utilisateurs de modifier l'historique ou de supprimer une validation de l'historique, les utilisateurs qui ont cette autorisation peuvent supprimer une modification et son historique du serveur. Ils peuvent également modifier l'historique de validation du référentiel du serveur. Au niveau de la branche, peut réécrire et détruire l'historique de la branche.
Création de balise	CreateTag	GitRepositories	Peut émettre des balises sur le référentiel et modifier ou supprimer les balises des éléments si l'utilisateur dispose également de l'autorisation Forcer.

Remarques :

1. Pour les Administrateurs de la collection de projets et les Comptes de service de la collection de projets, toutes les autorisations sont définies sur Autoriser l'héritage.

   Les groupes Readers et Comptes de service de build de la collection de projets disposent d'autorisations limitées à l'affichage : Lire.

2. Envisagez d'ajouter toutes les autorisations à tout utilisateur ou groupe ajouté manuellement qui collabore au développement du projet.

Autorisations Lab Management

Les autorisations Visual Studio Lab Management sont spécifiques aux ordinateurs virtuels, aux environnements et aux autres ressources. Toutes les autorisations sur cet objet sont aussi accordées automatiquement au créateur d'un objet dans Lab Management. Vous pouvez définir ces autorisations à l'aide de l'outil en ligne de commande TFSLabConfig.

Par défaut, les groupes Lecteurs au niveau du projet et au niveau de la collection ne disposent que d'autorisations Affichage des ressources de laboratoire (Lecture).

Nom de l'autorisation	TFSLabConfig perm	Description	Contributors (remarque 1)	Project Administrators	Compte de service de build de la collection de projets	Team Foundation Administrators, Project Collection Administrators
Supprimer l'environnement et les ordinateurs virtuels	Supprimer	Peut supprimer des environnements et des modèles. L'autorisation est activée pour l'objet en cours de suppression.
Supprimer des emplacements de laboratoire	DeleteLocation	Peut supprimer les emplacements des ressources Lab Management qui incluent des groupes hôtes de collection, des partages de bibliothèque de collection, des groupes hôtes de projet et des partages de bibliothèque de projet. Pour supprimer un emplacement, vous devez avoir l'autorisation Supprimer un emplacement de laboratoire pour cet emplacement.
Modifier l'environnement et les ordinateurs virtuels	Modifier	Peut modifier des environnements et des modèles. L'autorisation est activée pour l'objet en cours de modification.
Opérations d'environnement	EnvironmentOps	Peut démarrer, arrêter, suspendre et gérer des instantanés, ainsi que réaliser d'autres opérations sur un environnement.
Importer l'ordinateur virtuel	Créer	Peut importer un ordinateur virtuel à partir d'un partage de bibliothèque VMM. Cette autorisation diffère de l'autorisation Écrire car elle crée seulement un objet dans Lab Management et n'écrit aucune donnée dans le partage de bibliothèque ou le groupe hôte Virtual Machine Manager.
Gérer les autorisations enfants	ManageChildPermissions	Peut modifier les autorisations de tous les objets Lab Management enfants. Par exemple, si un utilisateur a l'autorisation Gérer des autorisations enfants pour un groupe hôte de projet d'équipe, l'utilisateur peut modifier les autorisations pour tous les environnements sous ce groupe hôte de projet d'équipe.
Gérer des emplacements de laboratoire	ManageLocation	Peut modifier les emplacements des ressources Lab Management qui incluent des groupes hôtes de collection, des partages de bibliothèque de collection, des groupes hôtes de projet et des partages de bibliothèque de projet. Pour modifier un emplacement spécifique, vous devez avoir l'autorisation Gérer un emplacement de laboratoire pour cet emplacement. Cette autorisation pour les emplacements au niveau de la collection (groupes hôtes de collection et partages de bibliothèque de collection) vous permet également de créer des emplacements au niveau du projet (groupe hôte de projet et partage de bibliothèque de projet).
Gérer les autorisations	ManagePermissions	Peut modifier les autorisations d'un objet Lab Management. Cette autorisation est activée pour l'objet dont les autorisations sont modifiées.
Gérer les instantanés	ManageSnapshots	Peut effectuer toutes les tâches de gestion des instantanées pour un environnement, qui incluent la prise d'un instantané, la restauration d'un instantané, le changement de son nom, sa suppression et sa lecture.
Suspendre un environnement	Suspendre	Peut suspendre un environnement.
Démarrer	Démarrer	Peut démarrer un environnement.
Arrêter	Arrêter	Peut arrêter un environnement.
Consulter des ressources de laboratoire	Lecture	Peut afficher les informations pour les différentes ressources Lab Management qui incluent des groupes hôtes de collection, des groupes hôtes de projet et l'environnement. Pour consulter les informations sur une ressource de laboratoire spécifique, vous devez avoir l'autorisation Consulter des ressources de laboratoire pour cette ressource.
Écrire dans l'environnement et les ordinateurs virtuels	Écrire	Peut créer des environnements pour un groupe hôte de projet. Les utilisateurs qui ont cette autorisation pour un partage de bibliothèque de projet peuvent stocker des environnements et des modèles.

Remarques :

1. Le groupe Readers dispose d'autorisations limitées à l'affichage : Lire.

Autorisations Release Management

Dans Release Management, vous pouvez affecter des autorisations en fonction du rôle affecté à un utilisateur, des autorisations fonctionnelles explicites affectées à des groupes ou des autorisations attribuées à des instances spécifiques d'un objet de version. En outre, vous pouvez affecter des approbateurs et des validateurs à des étapes spécifiques dans un chemin d'accès de version pour garantir que les applications déployées sont conformes aux normes de qualité.

• Basée sur les rôles : les deux rôles sont Gestionnaire de versions et Utilisateur du service. Les gestionnaires de versions peuvent gérer toutes les fonctions, indépendamment des groupes auxquels ils sont liés. L'utilisateur du service correspond à un rôle de compte de service. Pour limiter l'accès utilisateur, ne les affectez pas à un rôle. Faites-les plutôt hériter des autorisations affectées au groupe auquel ils sont liés.

• Groupe : pour restreindre l'accès aux zones fonctionnelles spécifiques, vous devez affecter les autorisations permises par ce groupe. Les membres de ce groupe héritent des autorisations affectées au groupe. La restriction de l'accès requiert que vous modifiez les autorisations accordées au groupe Tout le monde, qui par défaut a toutes les autorisations.

• Objet : outre les rôles et les groupes, vous pouvez limiter l'accès à la modification, à l'affichage et à la gestion de la sécurité des chemins d'accès de version et des modèles de version. Vous devez effectuer cette opération dans l'onglet Sécurité sur le chemin d'accès de version et via la page Propriétés pour un modèle de version.

• Approbateurs et validateurs : les approbateurs et les validateurs doivent se déconnecter à chaque étape d'une version. Vous devez affecter des approbateurs et des validateurs lorsque vous configurez un chemin d'accès de version. Tous les approbateurs et les validateurs doivent être ajoutés en tant qu'utilisateurs ou membre du groupe dans Release Management.

Release Management définit un seul groupe par défaut, Tout le monde, auquel appartiennent tous les comptes que vous ajoutez dans Release Management. De plus, des autorisations spécifiques sont allouées aux rôles Gestionnaire de contenu et Utilisateur du service.

Vous devez gérer les autorisations Release Management à partir du client Release Management. Vous pouvez définir ces autorisations en ouvrant le sous-menu indiqué dans la colonne Où définir. Pour en savoir plus sur la façon de définir ces autorisations, consultez Ajouter des utilisateurs, des groupes et le contrôle d'accès à Release Management. Pour installer Release Management, allez ici.

Nom de l'autorisation ou rôle d'utilisateur	Où définir	Description	Tout le monde	Rôle Gestionnaire de versions	Rôle d'utilisateur du service
Release Manager	Page Administration > Mon profil et Nouvel utilisateur	Peut administrer le serveur Release Management, gérer la connexion entre TFS et Release Management, et gérer les objets suivants : Les chemins d'accès à la version finale et les informations sur l'étape définies dans un chemin d'accès à la version finale. Les modèles de version, notamment l'ajout d'outils personnalisés et d'actions et l'ajout d'une séquence de déploiement et de variables de configuration pour toutes les étapes définies dans un modèle de version. La sécurité pour toutes les zones fonctionnelles. Envisagez d'ajouter : les utilisateurs qui administreront le serveur Release Management.
Utilisateur du service	Page Administration > Mon profil et Nouvel utilisateur	Peut gérer des déploiements ou des pools d'applications web. Envisagez d'ajouter : les ID de compte de service affectés à l'exécution des pools d'applications serveur, le service Windows de l'agent de déploiement et la surveillance de Release Management des services Windows.
Vue	Configurer les applications > Modèle de version > Propriétés Configurer les chemins d'accès > Chemins d'accès à la version finale	Peut afficher des modèles de version ou des chemins d'accès à la version finale et assigner sélectivement à certains utilisateurs un accès en lecture à des modèles de version et des chemins d'accès à la version finale spécifiques. Envisagez d'ajouter : les utilisateurs ou les groupes qui ont besoin d'afficher des modèles de version ou des chemins d'accès à la version finale spécifiques, sans les modifier.
Modifier	Configurer les applications > Modèle de version > Propriétés Configurer les chemins d'accès > Chemins d'accès à la version finale	Peut modifier des modèles de version ou des chemins d'accès à la version finale et choisir quels utilisateurs peuvent modifier des modèles de version et des chemins d'accès à la version finale spécifiques. Envisagez d'ajouter : les utilisateurs ou les groupes qui ont besoin de modifier des modèles de version et des chemins d'accès à la version finale spécifiques.
Peut créer une version	Configurer les applications > Modèle de version > Propriétés	Peut lancer une version et spécifier quels utilisateurs peuvent lancer une version à partir des modèles de version qu'ils peuvent consulter. Envisagez d'ajouter : les utilisateurs ou les groupes qui initialiseront une version. Avec cette autorisation, vous pouvez spécifier quels utilisateurs peuvent lancer une version à partir des modèles de version qu'ils peuvent consulter.
Gérer la sécurité	Configurer les applications > Modèle de version > Propriétés Configurer les chemins d'accès > Chemins d'accès à la version finale	Peut gérer quels groupes sont autorisés à afficher, modifier ou gérer des modèles de version ou des chemins d'accès à la version finale. Envisagez d'ajouter : les utilisateurs ou les groupes qui décideront quels groupes sont autorisés à afficher, modifier ou gérer des modèles de version ou des chemins d'accès à la version finale. Avec cette autorisation, les créateurs de modèles de version et les chemins d'accès de version peuvent contrôler qui peut afficher, modifier, ou libérer les modèles spécifiques ou les chemins d'accès.
Peut créer un modèle de version	Configurer les applications > Modèle de version	Peut définir des modèles de version. Sans cette autorisation, le bouton Nouveau de l'onglet Configurer les applications > Modèle de version est masqué. Envisagez d'ajouter : les utilisateurs ou les groupes qui ont besoin de créer, démarrer ou approuver une version.
Peut créer un chemin d'accès à la version finale	Configurer les chemins d'accès > Chemins d'accès à la version finale	Peut définir les étapes, le processus d'approbation et la sécurité des chemins d'accès à la version finale. Sans cette autorisation, le bouton Nouveau de l'onglet de Configurer les chemins d'accès > Chemins d'accès à la version finale est masqué. Envisagez d'ajouter : les utilisateurs ou les groupes qui ont besoin de gérer la configuration release utilisée dans le déploiement d'applications.
Peut gérer l'environnement	Configurer les chemins d'accès > Environnements	Peut définir les étapes qui composent un chemin d'accès à la version finale, ainsi que les serveurs et la sécurité pour chaque étape. Sans cette autorisation, l'onglet Configurer les chemins d'accès > Environnements est masqué. Envisagez d'ajouter : les utilisateurs ou les groupes qui ont besoin de gérer les serveurs et les environnements utilisés pour définir les chemins d'accès à la version finale.
Peut gérer le serveur	Configurer les chemins d'accès > Serveur	Peut définir les chemins d'accès à la version finale pour le déploiement d'applications dans votre système. Cette autorisation prend en charge l'accès à la définition des serveurs à utiliser pour déployer des applications pour tester et organiser les serveurs de production et y accéder. Sans cette autorisation, l'onglet Configurer les chemins d'accès > Serveur est masqué. Envisagez d'ajouter : les utilisateurs ou les groupes qui définiront les chemins d'accès à la version finale pour le déploiement d'applications dans votre système. Cette autorisation prend en charge l'accès à la définition des serveurs utilisée pour déployer des applications pour tester, organiser et accéder aux serveurs de production.
Peut gérer les stocks	Stock > Actions et outils	Peut définir des outils ou actions personnalisés pour le déploiement d'applications dans votre système. Avec cette autorisation ils peuvent afficher, modifier, et créer des actions et des outils. Consultez Libérer des actions pour déployer une application destinée à Release Management. Sans cette autorisation, l'onglet Stock est masqué. Envisagez d'ajouter : les utilisateurs ou les groupes qui définiront des outils ou actions personnalisés pour le déploiement d'applications dans votre système. Avec cette autorisation, ils peuvent afficher, modifier et créer les actions et les outils utilisés dans les applications de déploiement.
Peut utiliser un outil personnalisé dans les actions et les composants	Configurer les applications > Composant > Déploiement Configurer les applications > Modèle de version > Composant > Déploiement	Peut modifier les champs Commande et Arguments lorsque Aucun outil est sélectionné. Sans cette autorisation, ils ne peuvent pas modifier ces champs. Envisagez d'ajouter : les utilisateurs ou les groupes qui définiront les chemins d'accès à la version finale ou les modèles de version, ou qui initialiseront des versions. Cela leur permet de modifier les champs Commande et Arguments lorsque Aucun outil est sélectionné.
Modifier les valeurs et les serveurs cibles	Configurer les applications > Modèle de version	Peut modifier la séquence de déploiement et les variables de configuration pour des versions ou des étapes spécifiques. Sans cette autorisation, les informations sur la phase sont en lecture seule. Envisagez d'ajouter : les utilisateurs ou les groupes qui définiront les chemins d'accès à la version finale ou les modèles de version, ou qui initialiseront des versions. Cela leur permet de modifier la séquence de déploiement et les variables de configuration pour des versions ou des étapes spécifiques.
Modifier les approbations et l'environnement	Configurer les chemins d'accès > Chemin d'accès à la version finale > Étapes	Peut modifier les approbations et les environnements pour une étape spécifique. Sans cette autorisation, les informations sur la phase sont en lecture seule. Envisagez d'ajouter : les utilisateurs ou les groupes qui définiront les chemins d'accès à la version finale ou les modèles de version. Cela leur permet de modifier des approbations et des environnements pour une étape spécifique. Sans cette autorisation, des informations sur l'étape sont en lecture seule.

Q et R

Q : Quelle est la différence entre les autorisations et les niveaux d'accès ?

R : Certaines fonctionnalités de TFS sont uniquement disponibles pour les utilisateurs qui ont un niveau de licence approprié pour ces fonctionnalités. L'accès à ces fonctionnalités n'est pas contrôlé par les autorisations mais par l'appartenance aux groupes de licence de Team Web Access. Consultez Modifier les niveaux d'accès.

Q : Quelles autorisations sont affectées aux administrateurs d'équipe ?

R : Plusieurs autorisations basées sur les rôles sont accordées aux administrateurs d'équipe. Elles sont décrites ici.

Q : Quelles sont les autorisations associées aux alertes ?

R : Aucune autorisation d'interface utilisateur n'est associée aux alertes auxquelles vous pouvez vous abonner par l'intermédiaire de TWA.

Par défaut, tous les Collaborateurs peuvent s'abonner eux-mêmes à des alertes. Les Administrateurs de collections de projets et les Administrateurs de projet ou les utilisateurs ou membres de groupes qui disposent de l'autorisation Modifier les informations au niveau de la collection ou Modifier les informations au niveau du projet peuvent définir des alertes pour d'autres personnes ou pour une équipe.

Vous pouvez gérer les autorisations d'alerte à l'aide de TFSSecurity au niveau de la collection. Le Service d'événements de Team Foundation Server est conçu pour être flexible et extensible.

Action TFSSecurity	Espace de noms TFSSecurity	Description	Administrateurs de la collection de projets et Comptes de service de la collection de projets
CREATE_SOAP_SUBSCRIPTION	EventSubscription	Peut créer un abonnement à un service web SOAP.
GENERIC_READ	EventSubscription	Peut afficher des événements d'abonnements définis pour un projet d'équipe.
GENERIC_WRITE	EventSubscription	Peut créer des alertes pour d'autres utilisateurs ou pour une équipe.
UNSUBSCRIBE	EventSubscription	Peut annuler l'abonnement à un événement.

Q : Quels outils ou fonctionnalités supplémentaires font référence à des groupes ?

R : Les fonctionnalités suivantes font référence à des groupes TFS intégrés et personnalisés (ceux que vous créez) :

• Requêtes d'élément de travail : opérateur Dans le groupe, Pas dans le groupe

• Champ (Définition) - Attribut d'élément XML enfant : attributs for et not

• Champ (Flux de travail) - Attribut d'élément XML enfant : attributs for et not

• Niveaux d'accès

Q : Qu'est-ce qu'un utilisateur autorisé ?Comment sont remplis les groupes d'utilisateurs autorisés ?

R : lorsque vous ajoutez des comptes d'utilisateur directement dans un groupe TFS ou via un groupe Windows, ils sont automatiquement ajoutés à l'un des groupes d'utilisateurs autorisés.

• serveur\Team Foundation Valid Users : tous les membres ajoutés aux groupes de niveau serveur.

• NomCollectionProjets\Team Foundation Valid Users : tous les membres ajoutés aux groupes de niveau collection de projets.

• NomProjetÉquipe\Project Valid Users : tous les membres ajoutés aux groupes de niveau projet.

Les autorisations par défaut affectées à ces groupes sont essentiellement limitées à un accès en lecture, comme Afficher les ressources de build, Afficher les informations au niveau du projet et Afficher les informations au niveau de la collection.

Cela signifie que tous les utilisateurs que vous ajoutez à un projet d'équipe peuvent afficher les objets d'autres projets d'équipe au sein d'une collection. Si vous avez besoin de limiter l'accès en lecture, vous pouvez définir des restrictions via le nœud du chemin de zone. Pour connaître d'autres méthodes, consultez Restreindre l'accès à des fonctions et tâches.

Si vous supprimez ou affectez à l'autorisation Afficher les informations au niveau de l'instance la valeur Refuser pour l'un des groupes d'utilisateurs valides, aucun utilisateur du groupe ne pourra accéder au projet d'équipe, à la collection ou au déploiement, selon le groupe défini.

Par ailleurs, l'élément VALIDUSER peut être utilisé afin d'autoriser ou de limiter l'accès pour le suivi des éléments de travail.

Q : Comment puis-je gérer les autorisations pour accéder aux rapports et au portail du projet ?

R : Pour plus d'informations sur la façon de définir des autorisations dans Reporting Services et Produits SharePoint pour les utilisateurs de TFS, consultez Définir les autorisations d'administrateur pour les collections de projets d'équipe et Définir les autorisations d'administrateur pour Team Foundation Server.

Pour obtenir des exemples pas à pas sur la création de groupes personnalisés, la configuration d'autorisations pour contrôler l'accès aux ressources et d'autres options, consultez Restreindre l'accès à des fonctions et tâches.