Informations de référence sur les groupes de sécurité, les comptes de service et les autorisations
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Cet article fournit une référence complète pour chaque utilisateur, groupe et autorisation intégré.
Pour obtenir une référence rapide aux affectations par défaut, consultez Autorisations et accès par défaut. Pour obtenir une vue d’ensemble de la façon dont les autorisations et la sécurité sont gérées, consultez À propos des autorisations, des accès et des groupes de sécurité, À propos des rôles de sécurité et des niveaux d’accès.
Pour savoir comment ajouter des utilisateurs à un groupe ou définir une autorisation spécifique que vous pouvez gérer via le portail web, consultez les ressources suivantes :
Utilisateurs et groupes
Wiki
DevOps
Remarque
Les images affichées dans votre portail web peuvent différer des images de cet article en raison des mises à jour système, mais la fonctionnalité de base reste la même, sauf indication explicite.
Comptes de service
Le système génère quelques comptes de service pour prendre en charge des opérations spécifiques. Le tableau suivant décrit ces comptes d’utilisateur, qui sont ajoutés au niveau de l’organisation ou du regroupement.
| Nom d'utilisateur | Description |
|---|---|
| Service du pool d’agents | Dispose de l’autorisation d’écouter la file d’attente de messages pour que le pool spécifique reçoive le travail. Dans la plupart des cas, vous n’avez pas besoin de gérer directement les membres du groupe : le processus d’inscription de l’agent le gère pour vous. Lorsque vous inscrivez l’agent, le compte de service que vous spécifiez (généralement le service réseau) est automatiquement ajouté. Responsable de l’exécution d’opérations de lecture/écriture Azure Boards et de la mise à jour des éléments de travail lorsque les objets GitHub changent. |
| Azure Boards | Ajouté lorsque Azure Boards est connecté à GitHub. Vous ne devez pas avoir à gérer les membres de ce groupe. Responsable de la gestion de la création de liens entre GitHub et Azure Boards. |
| PipelinesSDK | Ajouté si nécessaire pour prendre en charge les jetons d’étendue de service de stratégie Pipelines. Ce compte d’utilisateur est similaire aux identités de service de génération, mais prend en charge le verrouillage des autorisations séparément. Dans la pratique, les jetons qui impliquent cette identité reçoivent des autorisations en lecture seule pour les ressources de pipeline et la possibilité unique d’approuver les demandes de stratégie. Ce compte doit être traité de la même façon que les identités de service de build sont traitées. |
| Service de génération ProjectName | Dispose des autorisations nécessaires pour exécuter des services de build pour le projet et est un utilisateur hérité utilisé pour les builds XAML. Il s’agit automatiquement d’un membre du groupe de services de sécurité, qui est utilisé pour stocker les utilisateurs disposant d’autorisations, mais aucun autre groupe de sécurité. |
| Service de build de la collection de projets | Dispose des autorisations nécessaires pour exécuter des services de génération pour la collection. Il s’agit automatiquement d’un membre du groupe de services de sécurité, qui est utilisé pour stocker les utilisateurs disposant d’autorisations, mais aucun autre groupe de sécurité. |
Groupes
Vous pouvez accorder des autorisations directement à un individu ou à un groupe. L’utilisation de groupes simplifie les choses et le système fournit plusieurs groupes intégrés à cet effet. Ces groupes et les autorisations par défaut qu’ils reçoivent sont définies à différents niveaux : serveur (déploiement local uniquement), collection de projets, projet et objets spécifiques. Vous pouvez également créer vos propres groupes et leur accorder l’ensemble spécifique d’autorisations approprié pour certains rôles de votre organisation.
Remarque
Les groupes de sécurité sont gérés au niveau de l’organisation, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupe au sein d’une organisation, vous pouvez utiliser l’outil AZURE DevOps CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.
Remarque
Les groupes de sécurité sont gérés au niveau du regroupement, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupes au sein d’une collection, vous pouvez utiliser l’outil AZURE DevOps CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.
Remarque
Les groupes de sécurité sont gérés au niveau du regroupement, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupes d’une collection, vous pouvez utiliser les API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.
Groupes au niveau du serveur
Lorsque vous installez Azure DevOps Server, le système crée des groupes par défaut disposant d’autorisations au niveau du déploiement au niveau du serveur. Vous ne pouvez pas supprimer ou supprimer les groupes intégrés au niveau du serveur.
Vous ne pouvez pas supprimer ou supprimer les groupes de niveau serveur par défaut.
Le nom complet de chacun de ces groupes est [Team Foundation]\{nom du groupe}. Par conséquent, le nom complet du groupe Administrateurs au niveau du serveur est [Team Foundation]\Team Foundation Administrators.
Nom du groupe
autorisations
Appartenance
Comptes de service Azure DevOps
Dispose d’autorisations au niveau du service pour l’instance de serveur.
Contient le compte de service fourni pendant l’installation
Ce groupe doit contenir uniquement des comptes de service et non des comptes d’utilisateur ou des groupes qui contiennent des comptes d’utilisateur. Par défaut, ce groupe est membre des administrateurs Team Foundation.
Pour ajouter un compte à ce groupe après avoir installé Azure DevOps Server, utilisez l’utilitaire TFSSecurity.exe dans le sous-dossier Outils de votre répertoire d’installation local. Utilisez la commande suivante : TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://azuredevopsservername.
Comptes de service proxy Azure DevOps
Dispose d’autorisations de niveau de service pour le proxy Azure DevOps Server et certaines autorisations au niveau du service.
Remarque
Ce compte est créé lorsque vous installez le service proxy Azure DevOps.
Ce groupe doit contenir uniquement des comptes de service et non des comptes d’utilisateur ou des groupes qui contiennent des comptes d’utilisateur.
Utilisateurs valides Azure DevOps
Dispose de l’autorisation d’afficher les informations au niveau de l’instance du serveur.
Contient tous les utilisateurs connus pour exister dans l’instance de serveur. Vous ne pouvez pas modifier l’appartenance à ce groupe.
Administrateurs Team Foundation
Dispose des autorisations nécessaires pour effectuer toutes les opérations au niveau du serveur.
Groupe Administrateurs locaux (BUILTIN\Administrators) pour n’importe quel serveur qui héberge les services d’application Azure DevOPs/Team Foundation.
Serveur \Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.
Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur les opérations au niveau du serveur.
Remarque
Si votre déploiement utilise Reporting, envisagez d’ajouter les membres de ce groupe aux groupes Gestionnaires de contenu dans Reporting Services.
Groupes au niveau de la collection
Lorsque vous créez une organisation ou une collection de projets dans Azure DevOps, le système crée des groupes au niveau du regroupement disposant d’autorisations dans cette collection. Vous ne pouvez pas supprimer ou supprimer les groupes intégrés au niveau de la collection.
Remarque
Pour activer la page d’aperçu des paramètres des autorisations des organisations v2 , consultez Activer les fonctionnalités d’aperçu. La page d’aperçu fournit une page de paramètres de groupe que la page active ne contient pas.
La page d’aperçu n’est pas disponible pour les versions locales.
Le nom complet de chacun de ces groupes est [{nom de la collection}]\{nom du groupe}. Par conséquent, le nom complet du groupe d’administrateurs pour la collection par défaut est [Collection par défaut]\Administrateurs de collection de projets.
Nom du groupe
autorisations
Appartenance
Project Collection Administrators
Dispose des autorisations nécessaires pour effectuer toutes les opérations pour la collection.
Contient le groupe Administrateurs locaux (BUILTIN\Administrators) pour le serveur sur lequel les services de la couche Application sont installés. Contient les membres du groupe Comptes de service CollectionName/. Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur la collection.
Remarque
Si votre déploiement utilise Reporting Services, envisagez d’ajouter les membres de ce groupe aux groupes Gestionnaires de contenu Team Foundation dans Reporting Services.
Collection de projets d’administrateurs de build
Dispose des autorisations nécessaires pour administrer les ressources de build et les autorisations pour la collection.
Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur les serveurs de build et les services pour cette collection.
Créer des comptes de service de la collection de projets
Dispose des autorisations nécessaires pour exécuter des services de génération pour la collection.
Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service. Il s’agit d’un groupe hérité utilisé pour les builds XAML. Utilisez l’utilisateur du service de génération de regroupement de projets ({votre organisation}) pour gérer les autorisations pour les builds actuelles.
Comptes de service proxy de la collection de projets
Dispose des autorisations nécessaires pour exécuter le service proxy pour la collection.
Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service.
Comptes de service de la collection de projets
Dispose des autorisations de niveau de service pour la collection et pour Azure DevOps Server.
Contient le compte de service fourni lors de l’installation. Ce groupe doit contenir uniquement des comptes de service et des groupes qui contiennent uniquement des comptes de service. Par défaut, ce groupe est membre du groupe Administrateurs.
Comptes de service test de la collection de projets
Dispose des autorisations de service de test pour la collection.
Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service.
Utilisateurs valides de la collection de projets
Dispose des autorisations nécessaires pour accéder aux projets d’équipe et afficher des informations dans la collection.
Contient tous les utilisateurs et groupes ajoutés n’importe où dans la collection. Vous ne pouvez pas modifier l’appartenance à ce groupe.
A un accès limité pour afficher les paramètres de l’organisation et les projets autres que ceux auxquels ils sont spécifiquement ajoutés. En outre, les options du sélecteur de personnes sont limitées à ces utilisateurs et groupes explicitement ajoutés au projet auxquels l’utilisateur est connecté.
Ajoutez des utilisateurs à ce groupe lorsque vous souhaitez limiter leur visibilité et leur accès à ces projets auxquels vous les ajoutez explicitement. n’ajoutez pas d’utilisateurs à ce groupe s’ils sont également ajoutés au groupe Administrateurs de collection de projets.
Remarque
Le groupe Utilisateurs dans l’étendue du projet devient disponible avec un accès limité lorsque la fonctionnalité d’aperçu au niveau de l’organisation, limiter la visibilité des utilisateurs et la collaboration à des projets spécifiques est activée. Pour plus d’informations, notamment sur les appels importants liés à la sécurité, consultez Gérer votre organisation, Limiter la visibilité des utilisateurs pour les projets, etc.
Groupes de services de sécurité
Permet de stocker des utilisateurs disposant d’autorisations, mais pas d’un autre groupe de sécurité.
N’affectez pas d’utilisateurs à ce groupe. Si vous supprimez des utilisateurs de tous les groupes de sécurité, vérifiez si vous devez les supprimer de ce groupe.
Groupes au niveau du projet
Pour chaque projet que vous créez, le système crée les groupes de niveau projet suivants. Ces groupes reçoivent des autorisations au niveau du projet.
Remarque
Pour activer la page d’aperçu de la page Paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.
La page d’aperçu n’est pas disponible pour les versions locales.
Conseil
Le nom complet de chacun de ces groupes est [{nom du projet}]\{nom du groupe}. Par exemple, le groupe contributeurs d’un projet appelé « Mon projet » est [Mon projet]\Contributeurs.
Nom du groupe
autorisations
Appartenance
Administrateurs de build
Dispose des autorisations nécessaires pour administrer les ressources de build et les autorisations de génération pour le projet. Les membres peuvent gérer des environnements de test, créer des exécutions de test et gérer des builds.
Affecter aux utilisateurs qui définissent et gèrent des pipelines de build.
Contributeurs
Dispose des autorisations nécessaires pour contribuer entièrement à la base de code du projet et au suivi des éléments de travail. Les autorisations principales qu’ils n’ont pas sont des autorisations qui gèrent ou administrent des ressources.
Par défaut, le groupe d’équipe créé lorsque vous créez un projet est ajouté à ce groupe, et tout utilisateur que vous ajoutez à l’équipe ou au projet est membre de ce groupe. En outre, toute équipe que vous créez pour un projet est ajoutée à ce groupe.
Lecteurs
Dispose des autorisations nécessaires pour afficher les informations du projet, la base de code, les éléments de travail et d’autres artefacts, mais pas les modifier.
Attribuez aux membres de votre organisation ou collection qui souhaitent fournir des autorisations d’affichage uniquement à un projet. Ces utilisateurs peuvent afficher les backlogs, les tableaux de bord, etc., mais pas ajouter ou modifier quoi que ce soit.
Dispose des autorisations nécessaires pour administrer tous les aspects des équipes et des projets, même s’ils ne peuvent pas créer de projets d’équipe.
Affecter aux utilisateurs qui ont besoin des fonctions suivantes : gérer les autorisations des utilisateurs, créer ou modifier des équipes, modifier les paramètres d’équipe, définir des chemins d’accès à la zone ou à l’itération ou personnaliser le suivi des éléments de travail. Les membres du groupe Administrateurs de projet disposent des autorisations nécessaires pour effectuer les tâches suivantes :
- Ajouter et supprimer des utilisateurs de l’appartenance au projet
- Ajouter et supprimer des groupes de sécurité personnalisés d’un projet
- Ajouter et administrer toutes les équipes de projet et fonctionnalités associées à l’équipe
- Modifier les listes de contrôle d’accès d’autorisation au niveau du projet
- Modifiez les abonnements aux événements (e-mail ou SOAP) pour les équipes ou les événements au niveau du projet.
Utilisateurs valides du projet
Dispose des autorisations d’accès et d’affichage des informations de projet.
Contient tous les utilisateurs et groupes ajoutés n’importe où au projet. Vous ne pouvez pas modifier l’appartenance à ce groupe.
Remarque
Nous vous recommandons de ne pas modifier les autorisations par défaut pour ce groupe.
Administrateurs de mise en production
Dispose des autorisations nécessaires pour gérer toutes les opérations de mise en production.
Affecter aux utilisateurs qui définissent et gèrent des pipelines de mise en production.
Remarque
Le groupe Administrateur de mise en production est créé en même temps que le premier pipeline de mise en production est défini. Elle n’est pas créée par défaut lorsque le projet est créé.
Dispose des autorisations nécessaires pour contribuer entièrement à la base de code du projet et au suivi des éléments de travail.
Le groupe d’équipe par défaut est créé lorsque vous créez un projet et, par défaut, est ajouté au groupe Contributeurs pour le projet. Toutes les nouvelles équipes que vous créez ont également un groupe créé pour eux et ajoutés au groupe Contributeurs.
Ajoutez des membres de l’équipe à ce groupe. Pour accorder l’accès pour configurer les paramètres d’équipe, ajoutez un membre de l’équipe au rôle d’administrateur d’équipe.
Rôle d’administrateur d’équipe
Pour chaque équipe que vous ajoutez, vous pouvez affecter un ou plusieurs membres d’équipe en tant qu’administrateurs. Le rôle d’administrateur d’équipe n’est pas un groupe avec un ensemble d’autorisations définies. Au lieu de cela, le rôle d’administrateur d’équipe est chargé de gérer les ressources d’équipe. Pour plus d’informations, consultez Gérer les équipes et configurer les outils d’équipe. Pour ajouter un utilisateur en tant qu’administrateur d’équipe, consultez Ajouter un administrateur d’équipe.
Remarque
Les administrateurs de projet peuvent gérer toutes les zones administratives d’équipe pour toutes les équipes.
autorisations
Le système gère les autorisations à différents niveaux (organisation, projet, objet et autorisations basées sur des rôles) et les affecte par défaut à un ou plusieurs groupes intégrés. Vous pouvez gérer la plupart des autorisations via le portail web. Gérez davantage d’autorisations avec l’outil en ligne de commande (CLI) .
Le système gère les autorisations à différents niveaux ( serveur, collection, projet, objet et autorisations basées sur des rôles) et les affecte par défaut à un ou plusieurs groupes intégrés. Vous pouvez gérer la plupart des autorisations via le portail web. Gérez davantage d’autorisations avec l’outil en ligne de commande (CLI) .
Dans les sections suivantes, l’autorisation d’espace de noms est fournie en suivant l’étiquette d’autorisation qui s’affiche dans l’interface utilisateur. Par exemple :
Créer une définition de balise
Tagging, Create
Pour plus d’informations, consultez Espace de noms de sécurité et la référence d’autorisation.
Autorisations au niveau du serveur
Gérez les autorisations au niveau du serveur via l’outil en ligne de commande Team Foundation Administration Console ou TFSSecurity. Les administrateurs Team Foundation bénéficient de toutes les autorisations au niveau du serveur. D’autres groupes au niveau du serveur ont sélectionné des attributions d’autorisations.
Autorisation (interface utilisateur)
Namespace permission
Description
Valide uniquement pour Azure DevOps Server 2020 et les versions antérieures configurées pour prendre en charge les rapports SQL Server. Peut traiter ou modifier les paramètres de l’entrepôt de données ou du cube d’analyse SQL Server à l’aide du service web de contrôle d’entrepôt.
D’autres autorisations peuvent être nécessaires pour traiter ou reconstruire entièrement l’entrepôt de données et le cube Analysis.
Peut créer et administrer des collections.
Peut supprimer un regroupement du déploiement.
Remarque
La suppression d’une collection ne supprime pas la base de données de collecte de SQL Server.
Peut modifier les autorisations au niveau du serveur pour les utilisateurs et les groupes, et ajouter ou supprimer des groupes de niveau serveur de la collection.
Remarque
Modifier les informations au niveau de l’instance inclut la possibilité d’effectuer ces tâches définies dans toutes les collections définies pour l’instance :
- Modifier les paramètres Extensions et Analytics
- Permet implicitement à l’utilisateur de modifier les autorisations de contrôle de version et les paramètres du référentiel
- Modifier les abonnements ou alertes d’événements pour les notifications globales, au niveau du projet et les événements au niveau de l’équipe
- Modifier tous les paramètres de projet et de niveau équipe pour les projets définis dans les collections
- Créer et modifier des listes globales
Pour accorder toutes ces autorisations à une invite de commandes, vous devez utiliser la tf.exe Permission commande pour accorder les autorisations et AdminConnections les AdminConfiguration autorisations en plus de GENERIC_WRITE.
Peut effectuer des opérations pour le compte d’autres utilisateurs ou services. Attribuez uniquement des comptes de service.
Peut déclencher des événements d’alerte au niveau du serveur. Attribuez uniquement des comptes de service et des membres du groupe Administrateurs Azure DevOps ou Team Foundation.
Peut utiliser toutes les fonctionnalités du portail web local. Cette autorisation est déconseillée avec Azure DevOps Server 2019 et versions ultérieures.
Remarque
Si l’autorisation Utiliser les fonctionnalités d’accès web complète est définie sur Refuser, l’utilisateur voit uniquement ces fonctionnalités autorisées pour le groupe parties prenantes (voir Modifier les niveaux d’accès). Un refus remplace toute autorisation implicite, même pour les comptes membres de groupes d’administration tels que les administrateurs Team Foundation.
Peut afficher l’appartenance au groupe au niveau du serveur et les autorisations de ces utilisateurs.
Remarque
L’autorisation Afficher les informations au niveau de l’instance est également affectée au groupe Utilisateurs valides Azure DevOps.
Autorisations au niveau de l’organisation
Gérez les autorisations au niveau de l’organisation via le contexte d’administration du portail web ou avec les commandes az devops security group. Les administrateurs de collection de projets reçoivent toutes les autorisations au niveau de l’organisation. D’autres groupes au niveau de l’organisation ont des attributions d’autorisations sélectionnées.
Remarque
Pour activer la page d’aperçu de la page Paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.
Important
L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou des regroupements, d’ajouter et de gérer l’appartenance à un groupe au niveau de l’organisation ou du regroupement, et de modifier les listes de contrôle d’accès d’autorisation au niveau du projet est attribuée à tous les membres du groupe Administrateurs de regroupement de projets. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.
Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de collection de projets. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.
Autorisation (interface utilisateur)
Namespace permission
Description
Généralités
Peut modifier les paramètres de trace pour collecter des informations de diagnostic plus détaillées sur les services Web Azure DevOps.
Peut ajouter un projet à une organisation ou à une collection de projets. D’autres autorisations peuvent être requises en fonction de votre déploiement local.
Peut supprimer un projet. La suppression d’un projet supprime toutes les données associées au projet. Vous ne pouvez pas annuler la suppression d’un projet, sauf en restaurant la collection à un point avant la suppression du projet.
Peut définir les paramètres au niveau de l’organisation et du projet.
Remarque
Modifier les informations au niveau de l’instance inclut la possibilité d’effectuer ces tâches pour tous les projets définis dans une organisation ou une collection :
- Modifier les paramètres de vue d’ensemble de l’organisation et les extensions
- Modifier les autorisations de contrôle de version et les paramètres du référentiel
- Modifier les abonnements ou alertes d’événements pour les notifications globales, au niveau du projet et les événements au niveau de l’équipe
- Modifier tous les paramètres de projet et de niveau équipe pour les projets définis dans les collections
Peut afficher les autorisations au niveau de l’organisation pour un utilisateur ou un groupe.
Compte de service
Peut effectuer des opérations pour le compte d’autres utilisateurs ou services. Attribuez cette autorisation uniquement aux comptes de service.
Peut déclencher des événements d’alerte de projet dans la collection. Attribuez uniquement des comptes de service.
Peut appeler les interfaces de programmation d’applications de synchronisation. Attribuez uniquement des comptes de service.
Boards
Peut modifier les autorisations pour personnaliser le suivi des travaux en créant et en personnalisant les processus hérités.
Peut créer un processus hérité utilisé pour personnaliser le suivi du travail et Azure Boards. Les utilisateurs disposant d’un accès de base et de partie prenante reçoivent cette autorisation par défaut.
Peut supprimer un processus hérité utilisé pour personnaliser le suivi du travail et Azure Boards.
Peut modifier un processus hérité personnalisé.
Référentiels
S’applique uniquement au contrôle de version Team Foundation (TFVC)
Peut supprimer des ensembles de rayons créés par d’autres utilisateurs.
Peut créer un espace de travail de contrôle de version. L’autorisation Créer un espace de travail est accordée à tous les utilisateurs dans le cadre de leur appartenance au groupe Utilisateurs valides de la collection de projets.
Pipelines
Administrer les autorisations de ressources de build
BuildAdministration, AdministerBuildResourcePermissions
Peut modifier les autorisations pour les ressources de génération au niveau de l’organisation ou de la collection de projets, notamment :
- Définir des stratégies de rétention
- Définir des limites de ressources pour les pipelines
- Ajouter et gérer des pools d’agents
- Ajouter et gérer des pools de déploiement
Remarque
En plus de cette autorisation, Azure DevOps fournit des autorisations basées sur les rôles régissant la sécurité des pools d’agents. D’autres paramètres au niveau de l’objet remplacent ceux définis au niveau de l’organisation ou du projet.
Peut gérer les ordinateurs de build, les agents de build et les contrôleurs de build.
Peut gérer les paramètres de pipeline définis par le biais des paramètres de l’organisation, des pipelines, des paramètres.
Peut réserver et allouer des agents de build. Attribuez uniquement des comptes de service pour les services de build.
Peut afficher, mais pas utiliser, générer des contrôleurs et des agents de build configurés pour une organisation ou une collection de projets.
Test Plans
Peut inscrire et désinscrire des contrôleurs de test.
Peut supprimer un flux d’audit. Les flux d’audit sont en préversion. Pour plus d’informations, consultez Créer un streaming d’audit.
Peut ajouter un flux d’audit. Les flux d’audit sont en préversion. Pour plus d’informations, consultez Créer un streaming d’audit.
Peut afficher et exporter les journaux d’audit. Les journaux d’audit sont en préversion. Pour plus d’informations, consultez Access, exporter et filtrer les journaux d’audit.
Stratégies
Peut activer et désactiver les stratégies de connexion d’application, comme décrit dans Modifier les stratégies de connexion d’application.
Autorisations au niveau de la collection
Gérez les autorisations au niveau de la collection via le contexte d’administrateur du portail web ou l’outil en ligne de commande TFSSecurity. Les administrateurs de collection de projets reçoivent toutes les autorisations au niveau du regroupement. D’autres groupes au niveau de la collection ont des affectations d’autorisations sélectionnées.
Les autorisations disponibles pour Azure DevOps Server 2019 et versions ultérieures varient en fonction du modèle de processus configuré pour la collection. Pour obtenir une vue d’ensemble des modèles de processus, consultez Personnaliser le suivi du travail.
Modèle de processus hérité
Modèle de processus XML local
Important
L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou des regroupements, d’ajouter et de gérer l’appartenance à un groupe au niveau de l’organisation ou du regroupement, et de modifier les listes de contrôle d’accès d’autorisation au niveau du projet est attribuée à tous les membres du groupe Administrateurs de regroupement de projets. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.
Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de collection de projets. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.
Autorisation (interface utilisateur)
Namespace permission
Description
Administrer les autorisations de ressources de build
BuildAdministration, AdministerBuildResourcePermissions
Peut modifier les autorisations pour les pipelines de build au niveau de la collection de projets. Cela inclut les artefacts suivants :
Peut modifier les autorisations pour personnaliser le suivi des travaux en créant et en personnalisant les processus hérités. Nécessite la configuration de la collection pour prendre en charge le modèle de processus hérité. Voir aussi :
Peut supprimer des ensembles de rayons créés par d’autres utilisateurs. S’applique quand TFVC est utilisé comme contrôle de code source.
Peut créer et supprimer des espaces de travail pour d’autres utilisateurs. S’applique quand TFVC est utilisé comme contrôle de code source.
Peut modifier les paramètres de trace pour collecter des informations de diagnostic plus détaillées sur les services Web Azure DevOps.
Peut créer un espace de travail de contrôle de version. S’applique quand TFVC est utilisé comme contrôle de code source. Cette autorisation est accordée à tous les utilisateurs dans le cadre de leur appartenance au groupe Utilisateurs valides de la collection de projets.
Peut ajouter des projets à une collection de projets. Des autorisations supplémentaires peuvent être requises en fonction de votre déploiement local.
Peut créer un processus hérité utilisé pour personnaliser le suivi du travail et Azure Boards. Nécessite la configuration de la collection pour prendre en charge le modèle de processus hérité.
Supprimer le champ de l’organisation
(anciennement Supprimer le champ du compte)
Collection, DELETE_FIELD
Peut supprimer un champ personnalisé ajouté à un processus. Pour les déploiements locaux, la collecte doit être configurée pour prendre en charge le modèle de processus hérité.
Peut supprimer un processus hérité utilisé pour personnaliser le suivi du travail et Azure Boards. Nécessite la configuration de la collection pour prendre en charge le modèle de processus hérité.
Peut supprimer un projet.
Remarque
La suppression d’un projet supprime toutes les données associées au projet. Vous ne pouvez pas annuler la suppression d’un projet, à l’exception de la restauration de la collection à un point avant la suppression du projet.
Peut définir les paramètres au niveau de l’organisation et du projet.
Remarque
Modifier les informations au niveau de la collection inclut la possibilité d’effectuer ces tâches pour tous les projets définis dans une organisation ou une collection :
- Modifier les extensions et les paramètres Analytics
- Modifier les autorisations de contrôle de version et les paramètres du référentiel
- Modifier les abonnements ou alertes d’événements pour les notifications globales, au niveau du projet et les événements au niveau de l’équipe
- Modifiez tous les paramètres de projet et de niveau équipe pour les projets définis dans les collections.
Peut modifier un processus hérité personnalisé. Nécessite la configuration de la collection pour prendre en charge le modèle de processus hérité.
Peut effectuer des opérations pour le compte d’autres utilisateurs ou services. Attribuez cette autorisation uniquement aux comptes de service locaux.
Peut gérer les ordinateurs de build, les agents de build et les contrôleurs de build.
Peut activer et désactiver les stratégies de connexion d’application, comme décrit dans Modifier les stratégies de connexion d’application.
Remarque
Cette autorisation est valide uniquement pour Azure DevOps Services. Bien qu’il apparaisse localement pour Azure DevOps Server, il ne s’applique pas aux serveurs locaux.
Peut télécharger, créer, modifier et charger des modèles de processus. Un modèle de processus définit les blocs de construction du système de suivi des éléments de travail ainsi que d’autres sous-systèmes auxquels vous accédez via Azure Boards. Nécessite la configuration de la collection pour prendre en charge le modèle de processus XML local ON=.
Peut inscrire et désinscrire des contrôleurs de test.
Peut déclencher des événements d’alerte de projet dans la collection. Attribuez uniquement des comptes de service. Les utilisateurs disposant de cette autorisation ne peuvent pas supprimer des groupes de niveau collection intégrés tels que les administrateurs de collection de projets.
Peut réserver et allouer des agents de build. Attribuez uniquement des comptes de service pour les services de build.
Peut afficher, mais pas utiliser, générer des contrôleurs et des agents de build configurés pour une organisation ou une collection de projets.
Afficher les informations au niveau de l’instance
ou Afficher les informations au niveau de la collection
Collection, GENERIC_READ
Peut afficher les autorisations au niveau de la collection pour un utilisateur ou un groupe.
Peut appeler les interfaces de programmation d’applications de synchronisation. Attribuez uniquement des comptes de service.
Autorisations au niveau du projet
Important
Pour accéder aux ressources au niveau du projet, l’autorisation Afficher les informations au niveau du projet doit être définie sur Autoriser. Cette autorisation porte toutes les autres autorisations au niveau du projet.
Gérez les autorisations au niveau du projet via le contexte d’administration du portail web ou avec les commandes az devops security group. Les administrateurs de projet disposent de toutes les autorisations au niveau du projet. D’autres groupes au niveau du projet ont des attributions d’autorisations sélectionnées.
Remarque
Pour activer la page d’aperçu de la page Paramètres des autorisations du projet , consultez Activer les fonctionnalités d’aperçu.
Gérez les autorisations au niveau du projet via le contexte d’administration du portail web. Les administrateurs de projet disposent de toutes les autorisations au niveau du projet. D’autres groupes au niveau du projet ont des attributions d’autorisations sélectionnées.
La page d’aperçu n’est pas disponible pour les versions locales.
Important
L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau du projet et d’ajouter et de gérer l’appartenance au groupe au niveau du projet est affectée à tous les membres du groupe Administrateurs de projet. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.
Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de projet. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.
Autorisation (interface utilisateur)
Namespace permission
Description
Généralités
Peut supprimer un projet d’une organisation ou d’une collection de projets.
Remarque
Même si vous définissez cette autorisation sur Refuser, les utilisateurs autorisés au niveau du projet peuvent probablement supprimer le projet pour lequel ils disposent d’autorisations. Pour vous assurer qu’un utilisateur ne peut pas supprimer un projet, veillez également à définir le projet d’équipe Supprimer au niveau du projet sur Refuser .
Peut effectuer les tâches suivantes pour le projet sélectionné défini dans une organisation ou un regroupement.
- Modifier la description du projet
- Modifiez la visibilité des service de projet.
Remarque
L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau du projet et d’ajouter et de gérer l’appartenance au groupe au niveau du projet est affectée à tous les membres du groupe Administrateurs de projet. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.
Peut fournir ou modifier des métadonnées pour un projet. Par exemple, un utilisateur peut fournir des informations générales sur le contenu d’un projet. La modification des métadonnées est prise en charge par le biais de l’API REST Définir les propriétés du projet.
Supprimer les notifications pour les mises à jour d’éléments de travail
Project, SUPPRESS_NOTIFICATIONS
Les utilisateurs disposant de cette autorisation peuvent mettre à jour des éléments de travail sans générer de notifications. Cette fonctionnalité est utile lorsque vous effectuez des migrations de mises à jour en bloc par des outils et que vous souhaitez ignorer la génération de notifications.
Envisagez d’accorder cette autorisation aux comptes de service ou aux utilisateurs disposant des règles de contournement sur l’autorisation de mise à jour des éléments de travail. Vous pouvez définir le paramètre sur le paramètre true lors de la suppressNotifications mise à jour via des éléments de travail - mettre à jour l’API REST.
Peut modifier la visibilité du projet de privé à public ou public en privé. S’applique uniquement à Azure DevOps Services.
Peut afficher les informations au niveau du projet, notamment l’appartenance au groupe d’informations de sécurité et les autorisations. Si vous définissez cette autorisation pour refuser pour un utilisateur, elle ne peut pas afficher le projet ni se connecter au projet.
Boards
Les utilisateurs disposant de cette autorisation peuvent enregistrer un élément de travail qui ignore les règles, telles que la copie, la contrainte ou les règles conditionnelles, définies pour le type d’élément de travail. Les scénarios utiles sont des migrations où vous ne souhaitez pas mettre à jour les champs by/date lors de l’importation ou lorsque vous souhaitez ignorer la validation d’un élément de travail.
Les règles peuvent être contournées de l’une des deux manières. La première consiste à utiliser les éléments de travail - mettre à jour l’API REST et définir le bypassRules paramètre truesur . La seconde consiste à utiliser le modèle objet client, en initialisant en mode règles de contournement (initialiser WorkItemStore avec WorkItemStoreFlags.BypassRules).
En cas de combinaison avec l’autorisation « Modifier les informations au niveau du projet », permet aux utilisateurs de modifier le processus d’héritage d’un projet. Pour plus d’informations, consultez Créer et gérer des processus hérités.
Peut ajouter des balises à un élément de travail. Par défaut, tous les membres du groupe Contributeurs disposent de cette autorisation. En outre, vous pouvez définir d’autres autorisations d’étiquetage par le biais d’outils de gestion de la sécurité. Pour plus d’informations, consultez l’espace de noms de sécurité et la référence d’autorisation, Étiquetage.
Remarque
Tous les utilisateurs ont accordé l’accès aux parties prenantes pour un projet privé ne peuvent ajouter que des balises existantes. Même si l’autorisation Créer une définition de balise est définie sur Autoriser, les parties prenantes ne peuvent pas ajouter de balises. Cela fait partie des paramètres d’accès des parties prenantes. Par défaut, les utilisateurs d’Azure DevOps Services ont accordé l’accès des parties prenantes pour un projet public. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.
Bien que l’autorisation Créer une définition de balise s’affiche dans les paramètres de sécurité au niveau du projet, les autorisations de balisage sont en fait des autorisations au niveau du regroupement qui sont délimitées au niveau du projet lorsqu’elles apparaissent dans l’interface utilisateur.
Pour étendre les autorisations d’étiquetage à un seul projet lors de l’utilisation de la commande TFSSecurity , vous devez fournir le GUID du projet dans le cadre de la syntaxe de commande.
Sinon, votre modification s’applique à l’ensemble de la collection.
Gardez cela à l’esprit lors de la modification ou de la définition de ces autorisations.
Supprimez et restaurez des éléments de travail ou supprimez des éléments de travail dans ce projet.
Project, WORK_ITEM_DELETE
Peut marquer les éléments de travail dans le projet comme supprimés. Par défaut, les utilisateurs d’Azure DevOps Services ont accordé l’accès des parties prenantes pour un projet public.
Peut déplacer un élément de travail d’un projet vers un autre projet dans la collection.
Supprimer définitivement les éléments de travail dans ce projet
Project, WORK_ITEM_PERMANENTLY_DELETE
Peut supprimer définitivement les éléments de travail de ce projet.
Analyse
Outre les AnalyticsView autorisations d’espace de noms répertoriées dans cette section, vous pouvez définir des autorisations au niveau de l’objet sur chaque vue.
Peut supprimer des vues Analytics sous la zone partagée.
Peut créer et modifier des vues d’analytique partagée.
Peut accéder aux données disponibles à partir du service Analytics. Pour plus d’informations, consultez Autorisations requises pour accéder au service Analytics.
Test Plans
Peut ajouter et supprimer des résultats de test et ajouter ou modifier des exécutions de test. Pour plus d’informations, consultez Contrôler la durée pendant laquelle conserver les résultats des tests et exécuter des tests manuels.
Peut supprimer une exécution de test.
Peut créer et supprimer des configurations de test.
Peut créer et supprimer des environnements de test.
Peut afficher les plans de test sous le chemin de la zone de projet.
Vues d’analyse (au niveau de l’objet)
Avec les vues d’analytique partagée, vous pouvez accorder des autorisations spécifiques pour afficher, modifier ou supprimer une vue que vous créez. Gérez la sécurité des vues Analytics à partir du portail web.
Les autorisations suivantes sont définies pour chaque vue Analyse partagée. Tous les utilisateurs valides reçoivent automatiquement toutes les autorisations pour gérer les vues Analytics. Envisagez d’accorder des autorisations de sélection à des vues partagées spécifiques à d’autres membres de l’équipe ou à un groupe de sécurité que vous créez. Pour plus d’informations, consultez Présentation des vues Analytics et informations de référence sur l’espace de noms et l’autorisation De sécurité.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut supprimer la vue Analyse partagée.
Peut modifier les paramètres de la vue Analyse partagée.
Peut afficher et utiliser la vue Analytique partagée à partir de Power BI Desktop.
Tableaux de bord (au niveau de l’objet)
Les autorisations pour les tableaux de bord d’équipe et de projet peuvent être définies individuellement. Les autorisations par défaut pour une équipe peuvent être définies pour un projet. Gérez la sécurité des tableaux de bord à partir du portail web. D’autres autorisations d’espace de noms sont prises en charge comme défini dans l’espace de noms security et la référence d’autorisation.
Autorisations du tableau de bord du projet
Par défaut, le créateur du tableau de bord du projet est le propriétaire du tableau de bord et a accordé toutes les autorisations pour ce tableau de bord.
PermissionNamespace permission |
Description |
|---|---|
Supprimer un tableau de bordDashboardsPrivileges, Delete |
Peut supprimer le tableau de bord du projet. |
Modifier le tableau de bordDashboardsPrivileges, Edit |
Peut ajouter des widgets et modifier la disposition du tableau de bord du projet. |
Gérer les autorisationsDashboardsPrivileges, ManagePermissions |
Peut gérer les autorisations pour le tableau de bord du projet. |
Les autorisations pour les tableaux de bord d’équipe peuvent être définies individuellement. Les autorisations par défaut pour une équipe peuvent être définies pour un projet. Gérez la sécurité des tableaux de bord à partir du portail web.
Autorisations par défaut du tableau de bord d’équipe
Par défaut, les administrateurs d’équipe disposent de toutes les autorisations pour leurs tableaux de bord d’équipe, notamment la gestion des autorisations par défaut et des autorisations de tableau de bord individuelles.
PermissionNamespace permission |
Description |
|---|---|
Créer des tableaux de bordDashboardsPrivileges, Create |
Peut créer un tableau de bord d’équipe. |
Supprimer des tableaux de bordDashboardsPrivileges, Delete |
Peut supprimer un tableau de bord d’équipe. |
Modifier les tableaux de bordDashboardsPrivileges, Edit |
Peut ajouter des widgets et modifier la disposition d’un tableau de bord d’équipe. |
Autorisations de tableau de bord d’équipe individuelles
Les administrateurs d’équipe peuvent modifier les autorisations des tableaux de bord d’équipe individuels en modifiant les deux autorisations suivantes.
PermissionNamespace permission |
Description |
|---|---|
Supprimer un tableau de bordDashboardsPrivileges, Delete |
Peut supprimer le tableau de bord d’équipe spécifique. |
Modifier le tableau de bordDashboardsPrivileges, Edit |
Peut ajouter des widgets et modifier la disposition du tableau de bord d’équipe spécifique. |
Pipeline ou build (au niveau de l’objet)
Gérez les autorisations de pipeline pour chaque pipeline défini dans le portail web ou à l’aide de l’outil en ligne de commande TFSSecurity. Les administrateurs de projet reçoivent toutes les autorisations de pipeline et les administrateurs de build reçoivent la plupart de ces autorisations. Vous pouvez définir des autorisations de pipeline pour tous les pipelines définis pour un projet ou pour chaque définition de pipeline.
Les autorisations dans Build suivent un modèle hiérarchique. Les valeurs par défaut de toutes les autorisations peuvent être définies au niveau du projet et peuvent être remplacées sur une définition de build individuelle.
Pour définir les autorisations au niveau du projet pour toutes les définitions de build d’un projet, choisissez Sécurité dans la barre d’action de la page principale du hub Builds.
Pour définir ou remplacer les autorisations d’une définition de build spécifique, choisissez Sécurité dans le menu contextuel de la définition de build.
Vous pouvez définir les autorisations suivantes dans Build aux deux niveaux.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut administrer les autorisations de génération pour d’autres utilisateurs.
Peut créer des lignes de pipeline et modifier ces pipelines.
Peut supprimer des définitions de build pour ce projet.
Peut supprimer définitivement une build terminée.
Modifier le pipeline de build : peut enregistrer les modifications apportées à un pipeline de build, notamment les variables de configuration, les déclencheurs, les référentiels et la stratégie de rétention. Disponible avec Azure DevOps Services, Azure DevOps Server 2019 1.1 et versions ultérieures. Remplace la définition de build.
Modifier la définition de build : peut créer et modifier des définitions de build pour ce projet.
Peut ajouter des informations sur la qualité de la build via Team Explorer ou le portail web.
Peut ajouter ou supprimer des qualités de construction. S’applique uniquement aux builds XAML.
Peut annuler, hiérarchiser ou reporter les builds mises en file d’attente. S’applique uniquement aux builds XAML.
Peut valider un ensemble de modifications TFVC qui affecte une définition de build contrôlée sans déclencher le système pour enregistrer et générer leurs modifications en premier.
Peut placer une build dans la 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.
Modifier la configuration de build de file d’attente Build, EditPipelineQueueConfigurationPermission
Peut spécifier des valeurs pour les paramètres de texte libre (par exemple, de type object ou array) et les variables de pipeline lors de la mise en file d’attente de nouvelles builds.
Peut activer indéfiniment l’indicateur de conservation sur une build. Cette fonctionnalité marque une build afin que le système ne le supprime pas automatiquement en fonction de toute stratégie de rétention applicable.
Peut arrêter toute build en cours, y compris les builds mises en file d’attente et démarrées par un autre utilisateur.
Peut ajouter des nœuds d’informations de génération au système et ajouter des informations sur la qualité d’une build. Attribuez uniquement des comptes de service.
Peut afficher les définitions de build créées pour le projet.
Peut afficher les builds mises en file d’attente et terminées pour ce projet.
Remarque
- Désactivez l’héritage pour une définition de build lorsque vous souhaitez contrôler les autorisations pour des définitions de build spécifiques.
- Lorsque l’héritage est Activé, la définition de build respecte les autorisations de génération définies au niveau du projet ou d’un groupe ou d’un utilisateur. Par exemple, un groupe Gestionnaires de build personnalisé dispose d’autorisations définies pour mettre manuellement en file d’attente une build pour le projet Fabrikam. Toute définition de build avec héritage Activé pour le projet Fabrikam permet à un membre du groupe Gestionnaires de build de mettre manuellement en file d’attente une build.
- Toutefois, en désactivant l’héritage pour le projet Fabrikam, vous pouvez définir des autorisations qui permettent uniquement aux administrateurs de projet de mettre manuellement en file d’attente une build pour une définition de build spécifique. Cela me permettrait ensuite de définir des autorisations pour cette définition de build spécifiquement.
- Attribuez la validation de la validation de remplacement par l’autorisation de build uniquement aux comptes de service pour les services de build et aux administrateurs de build qui sont responsables de la qualité du code. S’applique aux builds d’archivage contrôlé TFVC. Cela ne s’applique pas aux builds pr. Pour plus d’informations, consultez Archiver dans un dossier contrôlé par un processus de création d’archivage contrôlé.
Référentiel Git (au niveau de l’objet)
Gérez la sécurité de chaque dépôt ou branche Git à partir du portail web, de l’outil en ligne de commande TF ou de l’outil en ligne de commande TFSSecurity. Les administrateurs de projet bénéficient de la plupart de ces autorisations (qui s’affichent uniquement pour un projet configuré avec un dépôt Git). Vous pouvez gérer ces autorisations pour tous les dépôts Git ou pour un référentiel Git spécifique.
Remarque
Définissez les autorisations sur tous les référentiels Git en apportant des modifications à l’entrée de référentiels Git de niveau supérieur. Les dépôts individuels héritent des autorisations de l’entrée de référentiels Git de niveau supérieur. Les branches héritent des autorisations des affectations effectuées au niveau du référentiel. Par défaut, les groupes Lecteurs au niveau du projet disposent uniquement d’autorisations de lecture.
Pour gérer les autorisations de dépôt et de branche Git, consultez Définir des autorisations de branche.
Autorisation (interface utilisateur)
Namespace permission
Description
Contourner les stratégies lors de la fin des demandes de tirage
GitRepositories, PullRequestBypassPolicy
Vous pouvez choisir de remplacer les stratégies de branche en vérifiant les stratégies de branche de remplacement et en activant la fusion lors de la fin d’une demande de tirage.
Remarque
Ignorez les stratégies lors de la fin des demandes de tirage et des stratégies de contournement lors de l’envoi (push) du remplacement exempt de l’application de stratégie.
Peut envoyer (push) à une branche sur laquelle les stratégies de branche sont activées. Lorsqu'un utilisateur disposant de cette permission effectue un push qui remplacerait la stratégie de la branche, le push contourne automatiquement la stratégie de la branche sans étape d'acceptation ou d'avertissement.
Remarque
Ignorez les stratégies lors de la fin des demandes de tirage et des stratégies de contournement lors de l’envoi (push) du remplacement exempt de l’application de stratégie.
Au niveau du référentiel, vous pouvez envoyer (push) leurs modifications aux branches existantes dans le référentiel et effectuer des demandes de tirage ( pull requests). Les utilisateurs qui ne disposent pas de cette autorisation, mais qui disposent de l’autorisation Créer une branche peuvent envoyer des modifications à de nouvelles branches. Ne remplace pas les restrictions en place à partir des stratégies de branche.
Au niveau de la branche, vous pouvez envoyer (push) leurs modifications à la branche et verrouiller la branche. Le verrouillage d’une branche bloque les nouvelles validations d’autres utilisateurs et empêche d’autres utilisateurs de modifier l’historique de validation existant.
Peut créer, commenter et voter sur les demandes de tirage.
Peut créer et publier des branches dans le référentiel. L’absence de cette autorisation ne limite pas les utilisateurs à la création de branches dans leur référentiel local ; il les empêche simplement de publier des branches locales sur le serveur.
Remarque
Lorsque vous créez une branche sur le serveur, vous disposez de l’option Contribuer, Modifier des stratégies, Forcer l’envoi (push), gérer les autorisations et supprimer les autorisations de verrouillage d’autres personnes pour cette branche par défaut. Cela signifie que vous pouvez ajouter de nouvelles validations au dépôt via votre branche.
Peut créer des référentiels. Cette autorisation est disponible uniquement à partir de la boîte de dialogue Sécurité pour l’objet de référentiels Git de niveau supérieur.
Peut envoyer (push) des balises au référentiel.
Peut supprimer le référentiel. Au niveau des dépôts Git de niveau supérieur, vous pouvez supprimer n’importe quel dépôt.
Peut modifier des stratégies pour le référentiel et ses branches.
S’applique à TFS 2018 Update 2. Peut contourner les stratégies de branche et effectuer les deux actions suivantes :
- Remplacer les stratégies de branche et compléter les PR qui ne répondent pas à la stratégie de branche
- Envoyer (push) directement aux branches dont les stratégies de branche sont définies
Remarque
Dans Azure DevOps, il est remplacé par les deux autorisations suivantes : contourner les stratégies lors de la fin des demandes de tirage (pull requests) et de la déviation des stratégies lors de l’envoi (push).
Forcer l’envoi (réécriture de l’historique, supprimer des branches et des balises)
GitRepositories, ForcePush
Peut forcer une mise à jour vers une branche, supprimer une branche et modifier l’historique de validation d’une branche. Peut supprimer des balises et des notes.
Peut envoyer (push) et modifier des notes Git.
Peut définir des autorisations pour le référentiel.
Peut cloner, extraire, extraire et explorer le contenu du référentiel.
Peut supprimer les verrous de branche définis par d’autres utilisateurs. Le verrouillage d’une branche empêche les nouvelles validations d’être ajoutées à la branche par d’autres utilisateurs et empêche d’autres utilisateurs de modifier l’historique de validation existant.
Peut modifier le nom du référentiel. Lorsque vous définissez l’entrée de référentiels Git de niveau supérieur, vous pouvez modifier le nom de n’importe quel dépôt.
TFVC (au niveau de l’objet)
Gérez la sécurité de chaque branche TFVC à partir du portail web ou à l’aide de l’outil en ligne de commande TFSSecurity. Les administrateurs de projet bénéficient de la plupart de ces autorisations, qui s’affichent uniquement pour un projet configuré pour utiliser Team Foundation Version Control comme système de contrôle de code source. Dans les autorisations de contrôle de version, le refus explicite est prioritaire sur les autorisations de groupe d’administrateurs.
Ces autorisations s’affichent uniquement pour qu’une configuration de projet utilise Team Foundation Version Control comme système de contrôle de code source.
Dans les autorisations de contrôle de version, le refus explicite est prioritaire sur les autorisations de groupe d’administrateurs.
Autorisation (interface utilisateur)
Namespace permission
Description
Administrer des étiquettes
VersionControlItems, LabelOther
Peut modifier ou supprimer des étiquettes créées par un autre utilisateur.
Check-in
VersionControlItems, Checkin
Peut archiver les éléments et réviser les commentaires de l’ensemble de modifications validés. Les modifications en attente sont validées lors de l’archivage.*
Vérifier les modifications d’autres utilisateurs
VersionControlItems, CheckinOther
Peut archiver les modifications apportées par d’autres utilisateurs. Les modifications en attente sont validées lors de l’archivage.
Pendez une modification dans un espace de travail serveur
VersionControlItems, PendChange
Peut extraire et apporter une modification en attente aux éléments d’un dossier. Parmi les exemples de modifications en attente, citons l’ajout, la modification, le changement de nom, la suppression, la suppression, la création de branchements et la fusion d’un fichier. Les modifications en attente doivent être vérifiées. Les utilisateurs doivent donc également disposer de l’autorisation d’archivage pour partager leurs modifications avec l’équipe.*
Étiquette
VersionControlItems, Label
Peut étiqueter les éléments.
Peut verrouiller et déverrouiller des dossiers ou des fichiers. Un dossier ou un fichier suivi peut être verrouillé ou déverrouillé pour refuser ou restaurer les privilèges d’un utilisateur. Les privilèges incluent l’extraction d’un élément pour modification dans un autre espace de travail ou la vérification des modifications en attente d’un élément à partir d’un autre espace de travail. Pour plus d’informations, consultez commande Lock.
Gérer la branche
VersionControlItems, ManageBranch
Peut convertir n’importe quel dossier sous ce chemin d’accès en branche, et effectuer également les actions suivantes sur une branche : modifier ses propriétés, le réparer et le convertir en dossier. Les utilisateurs disposant de cette autorisation peuvent brancher cette branche uniquement s’ils disposent également de l’autorisation Fusion 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
VersionControlItems, AdminProjectRights
Peut gérer les autorisations d’autres utilisateurs pour les dossiers et les fichiers dans le contrôle de version.*
Peut fusionner les modifications dans ce chemin d’accès.*
Lire
VersionControlItems, Read
Peut lire le contenu d’un fichier ou d’un dossier. Si un utilisateur dispose d’autorisations de lecture pour un dossier, l’utilisateur peut voir le contenu du dossier et les propriétés des fichiers qu’il contient, même si l’utilisateur n’a pas l’autorisation d’ouvrir les fichiers.
Réviser les modifications des autres utilisateurs
VersionControlItems, ReviseOther
Peut modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.*
Annuler les modifications d’autres utilisateurs
VersionControlItems, UndoOther
Peut annuler une modification en attente apportée par un autre utilisateur.*
Déverrouiller les modifications d’autres utilisateurs
VersionControlItems, UnlockOther
Peut déverrouiller les fichiers verrouillés par d’autres utilisateurs.*
* Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement chargés de superviser ou de surveiller le projet et qui peuvent ou doivent modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.
Chemin d’accès de zone (niveau objet)
Les autorisations de chemin d’accès de zone gèrent l’accès aux branches de la hiérarchie de zones et aux éléments de travail dans ces zones. Gérez la sécurité de chaque chemin d’accès de zone à partir du portail web ou à l’aide de l’outil en ligne de commande TFSSecurity. Les autorisations de zone gèrent l’accès pour créer et gérer des chemins d’accès de zone, ainsi que créer et modifier des éléments de travail définis sous les chemins d’accès de zone.
Les membres du groupe Administrateurs de projet sont automatiquement autorisés à gérer les chemins d’accès de zone d’un projet. Envisagez d’accorder aux administrateurs d’équipe ou aux responsables d’équipe des autorisations pour créer, modifier ou supprimer des nœuds de zone.
Remarque
Plusieurs équipes peuvent contribuer à un projet. Lorsque c’est le cas, vous pouvez configurer des équipes associées à une zone. Les autorisations pour les éléments de travail de l’équipe sont affectées en affectant des autorisations à la zone. Il existe d’autres paramètres d’équipe qui configurent les outils de planification agile de l’équipe.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut créer des nœuds de zone. Les utilisateurs disposant de cette autorisation et de l’autorisation Modifier ce nœud peuvent déplacer ou réorganiser les nœuds de zone enfant.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds de zone.
Les utilisateurs disposant de cette autorisation et de l’autorisation Modifier ce nœud pour un autre nœud peuvent supprimer des nœuds de zone et reclassifier les éléments de travail existants du nœud supprimé. Si le nœud supprimé a des nœuds enfants, ces nœuds sont également supprimés.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds de zone.
Peut définir des autorisations pour ce nœud et renommer des nœuds de zone.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds de zone.
Peut modifier des éléments de travail dans ce nœud de zone.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de modifier les éléments de travail sous le nœud de zone.
Peut modifier les propriétés du plan de test, telles que les paramètres de génération et de test.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de gérer des plans de test ou des suites de test sous ce nœud de zone.
Peut créer et supprimer des suites de test, ajouter et supprimer des cas de test des suites de test, modifier les configurations de test associées aux suites de test et modifier la hiérarchie de suite (déplacer une suite de tests).
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de gérer des plans de test ou des suites de test sous ce nœud de zone.
Peut afficher les paramètres de sécurité d’un nœud de chemin d’accès de zone.
Peut afficher, mais pas modifier, les éléments de travail dans ce nœud de zone.
Remarque
Si vous définissez l’affichage des éléments de travail dans ce nœud sur Refuser, l’utilisateur ne peut pas voir d’éléments de travail dans ce nœud de zone. Un refus remplace toute autorisation implicite, même pour les utilisateurs membres d’un groupe d’administration.
Chemin d’itération (au niveau de l’objet)
Les autorisations de chemin d’itération gèrent l’accès pour créer et gérer des chemins d’itération, également appelés sprints.
Gérez la sécurité de chaque chemin d’itération à partir du portail web ou à l’aide de l’outil en ligne de commande TFSSecurity.
Les membres du groupe Administrateurs de projet reçoivent automatiquement ces autorisations pour chaque itération définie pour un projet. Envisagez d’accorder des autorisations aux administrateurs d’équipe, aux maîtres d’équipe ou à l’équipe pour créer, modifier ou supprimer des nœuds d’itération.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut créer des nœuds d’itération. Les utilisateurs disposant de cette autorisation et de l’autorisation Modifier ce nœud peuvent déplacer ou réorganiser les nœuds d’itération enfants.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds d’itération.
Les utilisateurs disposant de cette autorisation et de l’autorisation Modifier ce nœud pour un autre nœud peuvent supprimer des nœuds d’itération et reclassifier les éléments de travail existants du nœud supprimé. Si le nœud supprimé a des nœuds enfants, ces nœuds sont également supprimés.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds d’itération.
Peut définir des autorisations pour ce nœud et renommer des nœuds d’itération.
Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui peuvent avoir besoin de supprimer, d’ajouter ou de renommer des nœuds d’itération.
Peut afficher les paramètres de sécurité de ce nœud.
Remarque
Les membres de la collection de projets Utilisateurs valides, Utilisateurs valides du projet, ou tout utilisateur ou groupe disposant d’informations au niveau de la collection d’affichage ou afficher les informations au niveau du projet peuvent afficher les autorisations de n’importe quel nœud d’itération.
Requête d’élément de travail et dossier de requête (au niveau de l’objet)
Gérez les autorisations des requêtes et des dossiers de requête via le portail web. Les administrateurs de projet bénéficient de toutes ces autorisations. Les contributeurs reçoivent uniquement des autorisations en lecture.
Envisagez d’accorder les autorisations Contribuer aux utilisateurs ou aux groupes qui nécessitent la possibilité de créer et de partager des requêtes d’élément de travail pour le projet. Pour plus d’informations, consultez Définir des autorisations sur les requêtes.
Remarque
Pour créer des graphiques de requête, vous avez besoin d’un accès de base.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut afficher et modifier le dossier de requête ou enregistrer des requêtes dans le dossier.
Peut supprimer une requête ou un dossier de requête et son contenu.
Peut gérer les autorisations pour ce dossier de requête ou de requête.
Peut afficher et utiliser la requête ou les requêtes dans un dossier, mais ne peut pas modifier le contenu de la requête ou du dossier de requête.
Plans de remise (niveau objet)
Gérer les autorisations de plan via le portail web. Gérez les autorisations pour chaque plan via sa boîte de dialogue Sécurité. Les administrateurs de projet disposent de toutes les autorisations nécessaires pour créer, modifier et gérer des plans. Les utilisateurs valides disposent des autorisations d’affichage (en lecture seule).
Autorisation (interface utilisateur)
Namespace permission
Description
Peut supprimer le plan sélectionné.
Peut modifier la configuration et les paramètres définis pour le plan sélectionné.
Peut gérer les autorisations pour le plan sélectionné.
Peut afficher les listes des plans, ouvrir et interagir avec un plan, mais ne peut pas modifier la configuration ou les paramètres du plan.
Processus (au niveau de l’objet)
Vous pouvez gérer les autorisations pour chaque processus hérité que vous créez via le portail web. Gérez les autorisations pour chaque processus via sa boîte de dialogue Sécurité. Les administrateurs de collection de projets disposent de toutes les autorisations nécessaires pour créer, modifier et gérer des processus. Les utilisateurs valides disposent des autorisations d’affichage (en lecture seule).
Autorisation (interface utilisateur)
Namespace permission
Description
Peut définir ou modifier les autorisations d’un processus hérité.
Peut supprimer le processus hérité.
Peut créer un processus hérité à partir d’un processus système, ou copier ou modifier un processus hérité.
Étiquettes d’élément de travail
Vous pouvez gérer les autorisations d’étiquetage à l’aide de l’autorisation de sécurité az devops ou des outils en ligne de commande TFSSecurity . Les contributeurs peuvent ajouter des balises à des éléments de travail et les utiliser pour filtrer rapidement un backlog, un tableau ou une vue des résultats de requête.
Vous pouvez gérer les autorisations d’étiquetage à l’aide de l’outil en ligne de commande TFSSecurity. Les contributeurs peuvent ajouter des balises à des éléments de travail et les utiliser pour filtrer rapidement un backlog, un tableau ou une vue des résultats de requête.
Autorisation (interface utilisateur)
Namespace permission
Description
Peut créer de nouvelles balises et les appliquer aux éléments de travail. Les utilisateurs sans cette autorisation ne peuvent sélectionner que l’ensemble de balises existant pour le projet.
Par défaut, les contributeurs reçoivent l’autorisation Créer une définition de balise. Bien que l’autorisation Créer une définition de balise s’affiche dans les paramètres de sécurité au niveau du projet, les autorisations de balisage sont en fait des autorisations au niveau du regroupement qui sont délimitées au niveau du projet lorsqu’elles apparaissent dans l’interface utilisateur. Pour étendre les autorisations d’étiquetage à un seul projet lorsque vous utilisez un outil en ligne de commande, vous devez fournir le GUID du projet dans le cadre de la syntaxe de commande. Sinon, votre modification s’applique à l’ensemble de la collection. Gardez cela à l’esprit lors de la modification ou de la définition de ces autorisations.
Peut supprimer une balise de la liste des balises disponibles pour ce projet.
Cette autorisation n’apparaît pas dans l’interface utilisateur. Vous ne pouvez le définir qu’à l’aide d’un outil en ligne de commande. Il n’existe pas non plus d’interface utilisateur pour supprimer explicitement une balise. Au lieu de cela, lorsqu’une balise n’a pas été utilisée pendant trois jours, le système le supprime automatiquement.
Peut afficher la liste des balises disponibles pour l’élément de travail dans le projet. Les utilisateurs sans cette autorisation n’ont pas de liste de balises disponibles à partir desquelles choisir dans le formulaire d’élément de travail ou dans l’éditeur de requête.
Cette autorisation n’apparaît pas dans l’interface utilisateur. Il ne peut être défini qu’à l’aide d’un outil en ligne de commande. L’affichage des informations au niveau du projet permet implicitement aux utilisateurs d’afficher les balises existantes.
Peut renommer une balise à l’aide de l’API REST.
Cette autorisation n’apparaît pas dans l’interface utilisateur. Il ne peut être défini qu’à l’aide d’un outil en ligne de commande.
Release (au niveau de l’objet)
Gérez les autorisations pour chaque version définie dans le portail web. Les administrateurs de projet et les administrateurs de mise en production bénéficient de toutes les autorisations de gestion des mises en production. Ces autorisations fonctionnent dans un modèle hiérarchique au niveau du projet, pour un pipeline de mise en production spécifique ou pour un environnement spécifique dans un pipeline de mise en production. Dans cette hiérarchie, les autorisations peuvent être héritées du parent ou remplacées.
Remarque
Le groupe de l’administrateur de mise en production au niveau du projet est créé lorsque vous définissez votre premier pipeline de mise en production.
En outre, vous pouvez affecter des approbateurs à des étapes spécifiques dans un pipeline de mise en production pour vous assurer que les applications déployées répondent aux normes de qualité.
Les autorisations suivantes sont définies dans Release Management. La colonne d’étendue explique si l’autorisation peut être définie au niveau du projet, du pipeline de mise en production ou de l’environnement.
Permission
Description
Étendues
Peut modifier toutes les autres autorisations indiquées ici.
Projet, pipeline de mise en production, environnement
Peut créer de nouvelles mises en production.
Projet, pipeline de mise en production
Peut supprimer des pipelines de mise en production.
Projet, pipeline de mise en production
Peut supprimer des environnements dans des pipelines de mise en production.
Projet, pipeline de mise en production, environnement
Peut supprimer les mises en production d’un pipeline.
Projet, pipeline de mise en production
Peut ajouter et modifier un pipeline de mise en production, y compris des variables de configuration, des déclencheurs, des artefacts et une stratégie de rétention, ainsi que la configuration dans un environnement du pipeline de mise en production. Pour apporter des modifications à un environnement spécifique dans un pipeline de mise en production, l’utilisateur a également besoin de l’autorisation Modifier l’environnement de mise en production.
Projet, pipeline de mise en production
Peut modifier des environnements dans des pipelines de mise en production. Pour enregistrer les modifications apportées au pipeline de mise en production, l’utilisateur a également besoin de l’autorisation Modifier le pipeline de mise en production. Cette autorisation contrôle également si un utilisateur peut modifier la configuration à l’intérieur de l’environnement d’une instance de mise en production spécifique. Il doit aussi disposer de l’autorisation Gérer les mises en production pour pouvoir enregistrer la mise en production modifiée.
Projet, pipeline de mise en production, environnement
Peut lancer un déploiement direct d’une version vers un environnement. Cette autorisation concerne uniquement les déploiements directs qui sont initiés manuellement en sélectionnant l’action Déployer dans une version. Si la condition d’un environnement est définie sur n’importe quel type de déploiement automatique, le système lance automatiquement le déploiement sans vérifier l’autorisation de l’utilisateur qui a créé la version.
Projet, pipeline de mise en production, environnement
Peut ajouter ou modifier des approbateurs pour les environnements dans les pipelines de mise en production. Cette autorisation contrôle également si un utilisateur peut modifier les approbateurs dans l’environnement d’une instance de mise en production spécifique.
Projet, pipeline de mise en production, environnement
Peut modifier une configuration de mise en production, telle que des phases, des approbateurs et des variables. Pour modifier la configuration d’un environnement spécifique dans une instance de mise en production, l’utilisateur a également besoin de l’autorisation Modifier l’environnement de mise en production.
Projet, pipeline de mise en production
Peut afficher les pipelines de mise en production.
Projet, pipeline de mise en production
Peut afficher les versions appartenant aux pipelines de mise en production.
Projet, pipeline de mise en production
Les valeurs par défaut de toutes ces autorisations sont définies pour les collections de projets d’équipe et les groupes de projets. Par exemple, les administrateurs de collection de projets, les administrateurs de projet et les administrateurs de mise en production reçoivent toutes les autorisations ci-dessus par défaut. Les contributeurs reçoivent toutes les autorisations, sauf Administrer les autorisations de mise en production. Les lecteurs, par défaut, sont refusés à toutes les autorisations, à l’exception du pipeline de mise en production d’affichage et des versions d’affichage.
Autorisations du groupe de tâches (build et mise en production)
Gérez les autorisations pour les groupes de tâches à partir du hub Build et Release du portail web. Les administrateurs de projet, de build et de mise en production disposent de toutes les autorisations. Les autorisations des groupes de tâches suivent un modèle hiérarchique. Les valeurs par défaut de toutes les autorisations peuvent être définies au niveau du projet et peuvent être remplacées sur une définition de groupe de tâches individuelle.
Utilisez des groupes de tâches pour encapsuler une séquence de tâches déjà définie dans une build ou une définition de mise en production dans une tâche réutilisable unique. Définissez et gérez des groupes de tâches dans l’onglet Groupes de tâches du hub build et release .
Autorisation Description Administrer les autorisations des groupes de tâches Peut ajouter et supprimer des utilisateurs ou des groupes à la sécurité du groupe de tâches. Supprimer le groupe de tâches Peut supprimer un groupe de tâches. Modifier le groupe de tâches Peut créer, modifier et supprimer un groupe de tâches.
Notifications ou alertes
Aucune autorisation d’interface utilisateur n’est associée à la gestion des Notifications par e-mail ou des alertes. Au lieu de cela, vous pouvez les gérer à l’aide de l’outil en ligne de commande TFSSecurity .
- Par défaut, les membres du groupe Contributeurs au niveau du projet peuvent s’abonner aux alertes pour eux-mêmes.
- Les membres du groupe Administrateurs de collection de projets ou utilisateurs disposant des informations de niveau collection Modifier peuvent définir des alertes dans cette collection pour d’autres personnes ou pour une équipe.
- Les membres du groupe Administrateurs de projet ou les utilisateurs qui ont les informations de niveau projet modifier peuvent définir des alertes dans ce projet pour d’autres personnes ou pour une équipe.
Vous pouvez gérer les autorisations d’alerte à l’aide de TFSSecurity.
TFSSecurity Action
Espace de noms TFSSecurity
Description
Administrateurs de collection de projets &
Comptes de service de collecte de projets
CREATE_SOAP_SUBSCRIPTION
EventSubscription
Peut créer un abonnement de service web basé sur SOAP.
✔️
GENERIC_READ
EventSubscription
Peut afficher les événements d’abonnement définis pour un projet.
✔️
GENERIC_WRITE
EventSubscription
Peut créer des alertes pour d’autres utilisateurs ou pour une équipe.
✔️
UNSUBSCRIBE
EventSubscription
Peut se désabonner d’un abonnement aux événements.
✔️
Articles connexes
- Bien démarrer avec les autorisations, l’accès et les groupes de sécurité
- Espace de noms de sécurité et référence des autorisations pour Azure DevOps
- Ajouter des utilisateurs à une organisation (Azure DevOps Services)
- Ajouter des utilisateurs à une équipe ou à un projet
- Faire d’un utilisateur un administrateur d’équipe