Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 plus d’informations sur l’ajout d’utilisateurs à un groupe ou la définition d’une autorisation spécifique que vous pouvez gérer via le portail web, consultez les ressources suivantes :
Utilisateurs et groupes
Wiki
DevOps
Note
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.
Service accounts
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.
| User name | 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. |
| ProjectName Build Service | 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é. |
Groups
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.
Note
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é.
Note
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é.
Server-level groups
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.
Group name
Permissions
Membership
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.
To add an account to this group after you install Azure DevOps Server, use the TFSSecurity.exe utility in the Tools subfolder of your on-premises installation directory. 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.
Note
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.
Local Administrators group (BUILTIN\Administrators) for any server that hosts Azure DevOPs/Team Foundation application services.
Server\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.
Note
Si votre déploiement utilise Reporting, envisagez d’ajouter les membres de ce groupe aux groupes Gestionnaires de contenu dans Reporting Services.
Collection-level groups
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.
Note
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.
Group name
Permissions
Membership
Administrateurs de collection de projets
Dispose des autorisations nécessaires pour effectuer toutes les opérations pour la collection.
Contains the Local Administrators group (BUILTIN\Administrators) for the server where the application-tier services are installed. Contains the members of the CollectionName/Service Accounts group. Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur la collection.
Note
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.
Note
The Project-Scoped Users group becomes available with limited access when the organization-level preview feature, Limit user visibility and collaboration to specific projects is enabled. 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.
Project-level groups
Pour chaque projet que vous créez, le système crée les groupes de niveau projet suivants. These groups are assigned project-level permissions.
Note
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.
Tip
Le nom complet de chacun de ces groupes est [{nom du projet}]\{nom du groupe}. For example, the contributors group for a project called "My Project" is [My Project]\Contributors.
Group name
Permissions
Membership
Build Administrators
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.
Contributors
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.
Readers
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.
Note
Nous vous recommandons de ne pas modifier les autorisations par défaut pour ce groupe.
Release Administrators
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.
Note
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.
Note
Les administrateurs de projet peuvent gérer toutes les zones administratives d’équipe pour toutes les équipes.
Permissions
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. For example:
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.
Server-level permissions
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.
Permission (UI)
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.
Note
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.
Note
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 :
- Modify Extensions and Analytics settings
- Permet implicitement à l’utilisateur de modifier les autorisations de contrôle de version et les paramètres du référentiel
- Edit event subscriptions or alerts for global notifications, project-level, and team-level events
- 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 AdminConfiguration les AdminConnections 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.
Note
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.
Note
L’autorisation Afficher les informations au niveau de l’instance est également affectée au groupe Utilisateurs valides Azure DevOps.
Organization-level permissions
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.
Note
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.
Permission (UI)
Namespace permission
Description
General
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.
Note
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 :
- Modify organization Overview settings and Extensions
- Modifier les autorisations de contrôle de version et les paramètres du référentiel
- Edit event subscriptions or alerts for global notifications, project-level, and team-level events
- 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.
Service Account
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
Can modify permissions for customizing work tracking by creating and customizing inherited processes.
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é.
Repos
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
Note
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. Other, object-level settings will override those set at the organization or project-level.
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.
Policies
Peut activer et désactiver les stratégies de connexion d’application, comme décrit dans Modifier les stratégies de connexion d’application.
Collection-level permissions
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.
Permission (UI)
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 :
Can modify permissions for customizing work tracking by creating and customizing inherited processes. Nécessite la configuration de la collection pour prendre en charge le modèle de processus hérité. See also:
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.
Note
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.
Note
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 :
- Modify Extensions, and Analytics settings
- Modifier les autorisations de contrôle de version et les paramètres du référentiel
- Edit event subscriptions or alerts for global notifications, project-level, and team-level events
- 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. Assign this permission only to on-premises service accounts.
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.
Note
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.
Project-level permissions
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.
Note
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
The permission to add or remove project-level security groups and add and manage project-level group membership is assigned to all members of the Project Administrators group. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.
You can't change the permissions for the Project Administrators group. 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.
Permission (UI)
Namespace permission
Description
General
Peut supprimer un projet d’une organisation ou d’une collection de projets.
Note
Even if you set this permission to Deny, users granted permission at the project level can likely delete the project for which they have permission. 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.
Note
The permission to add or remove project-level security groups and add and manage project-level group membership is assigned to all members of the Project Administrators group. 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 suppressNotifications lors de la true 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. If you set this permission to Deny for a user, they can't view the project or sign in to the project.
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.
Note
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.
To scope tagging permissions to a single project when using the TFSSecurity command, you must provide the GUID for the project as part of the command syntax.
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.
Analytics
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.
Can delete Analytics views under the Shared area.
Peut créer et modifier des vues d’analytique partagée.
Can access data available from the Analytics service. 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.
Can create and delete test configurations.
Can create and delete test environments.
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. Manage the security of Analytics views from the web portal.
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 etinformations de référence sur l’espace de noms et l’autorisation De sécurité.
Permission (UI)
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.
Dashboards (object-level)
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 |
|---|---|
Delete dashboardDashboardsPrivileges, Delete |
Peut supprimer le tableau de bord du projet. |
Edit dashboardDashboardsPrivileges, Edit |
Peut ajouter des widgets et modifier la disposition du tableau de bord du projet. |
Manage PermissionsDashboardsPrivileges, 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 |
|---|---|
Create dashboardsDashboardsPrivileges, Create |
Peut créer un tableau de bord d’équipe. |
Delete dashboardsDashboardsPrivileges, Delete |
Peut supprimer un tableau de bord d’équipe. |
Edit dashboardsDashboardsPrivileges, 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 |
|---|---|
Delete dashboardDashboardsPrivileges, Delete |
Peut supprimer le tableau de bord d’équipe spécifique. |
Edit dashboardDashboardsPrivileges, 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.
To set the permissions at project level for all build definitions in a project, choose Security from the action bar on the main page of Builds hub.
To set or override the permissions for a specific build definition, choose Security from the context menu of the build definition.
Vous pouvez définir les autorisations suivantes dans Build aux deux niveaux.
Permission (UI)
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 créer des pipelines.
Peut supprimer des définitions de build pour ce projet.
Peut supprimer une build terminée. Builds that are deleted are retained in the Deleted tab for some time before they're destroyed.
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. Impossible de créer de nouveaux pipelines. Modifier la définition de build : peut créer et modifier des définitions de build pour ce projet.
Note
To control permissions for specific build definitions, turn off inheritance.
When inheritance is turned on, the build definition respects the build permissions defined at the project level or a group or user. 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 pour le projet Fabrikam permet à un membre du groupe Gestionnaires de build de mettre manuellement en file d’attente une build.
When inheritance is turned off, you can set permissions so only Project Administrators can manually queue a build for a specific build definition.
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.
Note
- Turn Inheritance Off for a build definition when you want to control permissions for specific build definitions.
- 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.
- However, by turning Inheritance Off for project Fabrikam, you can set permissions that only allow Project Administrators to manually queue a build for a specific build definition. 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)
Manage the security of each Git repository or branch from the web portal, the TF command line tool, or using the TFSSecurity command-line tool. 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.
Note
Set permissions across all Git repositories by making changes to the top-level Git repositories entry. Individual repositories inherit permissions from the top-level Git repositories entry. 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.
Permission (UI)
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.
Note
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.
Note
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). Users who lack this permission but who have the Create branch permission might push changes to new branches. Doesn't override restrictions in place from branch policies.
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.
Note
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. This permission is only available from the Security dialog for the top-level Git repositories object.
Peut envoyer (push) des balises au référentiel.
Peut supprimer le référentiel. At the top-level Git repositories level, can delete any repository.
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
Note
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.
Can remove branch locks set by other users. 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. When set at the top-level Git repositories entry, can change the name of any repository.
TFVC (object-level)
Manage the security of each TFVC branch from the web portal or using the TFSSecurity command-line tool. 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.
In version control permissions, explicit Deny takes precedence over administrator group permissions.
Permission (UI)
Namespace permission
Description
Administer labels
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.*
Label
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. For more information, see Lock command.
Manage branch
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.
Manage permissions
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.*
Read
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. Manage the security of each area path from the web portal or using the TFSSecurity command-line tool. 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.
Note
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. There are other team settings that configure the team's agile planning tools.
Permission (UI)
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.
Note
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. A Deny overrides any implicit allow, even for users that are members of an administrative groups.
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.
Manage the security of each iteration path from the web portal or using the TFSSecurity command-line tool.
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.
Permission (UI)
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.
Note
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)
Manage query and query folder permissions through the web portal. Les administrateurs de projet bénéficient de toutes ces autorisations. Les contributeurs reçoivent uniquement des autorisations en lecture.
Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project. Pour plus d’informations, consultez Définir des autorisations sur les requêtes.
Note
Pour créer des graphiques de requête, vous avez besoin d’un accès de base.
Permission (UI)
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)
Manage plan permissions through the web portal. 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).
Permission (UI)
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.
Process (object-level)
You can manage the permissions for each inherited process that you create through the web portal. 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).
Permission (UI)
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.
Permission (UI)
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 (object-level)
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.
Note
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
Scopes
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. The user also needs Manage releases permission to save the modified release.
Projet, pipeline de mise en production, environnement
Peut lancer un déploiement direct d’une version vers un environnement. This permission is only for direct deployments that are manually initiated by selecting the Deploy action in a release. 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. Contributors are given all permissions except Administer release permissions. Readers, by default, are denied all permissions except View release pipeline and View releases.
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 .
Permission 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. Instead, you can manage them using the TFSSecurity command-line tool.
- By default, members of the project level Contributors group can subscribe to alerts for themselves.
- 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.
- Members of the Project Administrators group, or users who have the Edit project-level information can set alerts in that project for others or for a team.
You can manage alert permissions using TFSSecurity.
TFSSecurity Action
TFSSecurity Namespace
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.
✔️
Related content
- 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
- Troubleshoot permissions