Groupes de sécurité, comptes de service et autorisations dans Azure DevOps

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 gestion des autorisations et de la sécurité, consultez Prise en main des autorisations, des accès et des groupes de sécurité. En plus des groupes de sécurité, il existe également des rôles de sécurité, qui fournissent des autorisations pour les zones sélectionnées.

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

• Ajouter des utilisateurs au groupe Project Administration istrators
• Ajouter des utilisateurs au groupe Administration istrators de collection de projets
• Ajouter des utilisateurs à une organisation
• Ajouter des utilisateurs à un projet ou à une équipe
• Ajouter un administrateur d'équipe

---

Wiki

• README &Wiki

DevOps

• Branche Git
• Dépôts Git
• TFVC
• Pipelines de build et de version
• Approbations et approbateurs
• Groupes de tâches
• Groupes de variables
• Ressources basées sur des rôles

Suivi du travail

• Chemins de zone et d’itération
• Requêtes et dossiers
• Autorisations de plan
• Personnaliser le processus

---

Génération d’états

• Autorisations du tableau de bord
• Analyse
• Vues Analytics

Remarque

Les images affichées dans votre portail web peuvent différer des images de cet article. Ces différences résultent des mises à jour apportées à Azure DevOps. Toutefois, les fonctionnalités de base disponibles restent les mêmes, sauf mention explicite.

Comptes de service

Il existe quelques comptes de service générés par le système 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 ne devez pas avoir à gérer les membres de ce groupe. Le processus d’inscription de l’agent s’en occupe pour vous. Le compte de service que vous spécifiez pour l’agent (couramment service réseau) est automatiquement ajouté lorsque vous inscrivez l’agent. 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 sont mis à jour.
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 est ajouté au groupe de services de sécurité, utilisé pour stocker les utilisateurs qui ont reçu des autorisations, mais qui n’ont pas été ajoutés à un 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 est ajouté au groupe de services de sécurité, utilisé pour stocker les utilisateurs qui ont reçu des autorisations, mais qui n’ont pas été ajoutés à un 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é appartiennent au niveau de l’organisation, même s’ils accèdent uniquement à un projet spécifique. Certains groupes peuvent être masqués dans le portail web en fonction des autorisations de l’utilisateur. Vous trouverez tous les noms de groupe dans une organisation avec l’outil AZURE devops CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

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 autorisations des organisations Paramètres Page 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 n’a pas.

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]\Collection de projets Administration istrators.

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 Local Administration istrators (BUILTIN\Administration istrators) pour le serveur sur lequel les services de la couche Application ont été installés. Contient les membres du groupe Comptes de service CollectionName/. Ce groupe doit être limité au plus petit nombre possible d’utilisateurs qui ont besoin d’un contrôle administratif total sur le regroupement.

Build de collection de projets Administration istrators

Dispose des autorisations nécessaires pour administrer les ressources de build et les autorisations pour la collection.

Limitez ce groupe au plus petit nombre possible d’utilisateurs qui ont besoin d’un contrôle administratif total sur les serveurs de build et les services pour cette collection.

Comptes de service de génération de regroupement 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 regroupement 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 collecte 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 Administration istrators.

Comptes de service de test de collecte 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 qui ont été ajoutés n’importe où dans la collection. Vous ne pouvez pas modifier l’appartenance à ce groupe.

Utilisateurs dans l’étendue du projet

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 qui ont été explicitement ajoutés au projet auquel 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 collection de projets Administration istrators.

Remarque

Le groupe Utilisateurs délimités par le projet devient disponible avec un accès restreint 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.

Groupe de services de sécurité

Permet de stocker les utilisateurs qui ont reçu des autorisations, mais qui n’ont pas été ajoutés à 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é, case activée 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 Autorisations de projet Paramètres Page, consultez Activer les fonctionnalités d’aperçu.

Page de préversion

Page active

Conseil

Le nom complet de chacun de ces groupes est [{nom du projet}]\{nom du groupe}. Par exemple, le groupe contributeur s pour 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.

Project Administration istrators

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.

Affectez aux utilisateurs qui gèrent les autorisations des utilisateurs, créent ou modifient des équipes, modifient les paramètres de l’équipe, définissent des chemins d’accès de zone ou d’itération, ou personnalisent le suivi des éléments de travail. Les membres du groupe Project Administration istrators 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 qui ont été 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.

Mises en production Administration istrateurs

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 Release Administration istrator 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éé.

TeamName

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 auront é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 Administration istrateurs 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. Vous pouvez gérer plusieurs autorisations à l’aide d’un ou plusieurs outils de gestion de la sécurité, en spécifiant une autorisation d’espace de noms.

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 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 Administration istrateurs 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 Autorisations de projet Paramètres Page, consultez Activer les fonctionnalités d’aperçu.

Page de préversion

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou de la collection, 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 et de regroupement est attribuée à tous les membres du groupe de regroupements de projets Administration istrators. 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 Administration istrators 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

Modifier les paramètres de trace
Collection, DIAGNOSTIC_TRACE

Peut modifier les paramètres de trace pour collecter des informations de diagnostic plus détaillées sur les services Web Azure DevOps.

Créer des projets
(anciennement Créer des projets d’équipe)
Collection, CREATE_PROJECTS

Peut ajouter un projet à une organisation ou à une collection de projets. D’autres autorisations peuvent être requises en fonction de votre déploiement local.

Supprimer le projet d’équipe
Project, DELETE

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.

Modifier les informations au niveau de l’instance
Collection, GENERIC_WRITE

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, les extensions et les paramètres d’ID Microsoft Entra
• 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.

Afficher les informations au niveau de l’instance
Collection, GENERIC_READ

Peut afficher les autorisations au niveau de l’organisation pour un utilisateur ou un groupe.

Compte de service

Effectuer des demandes pour le compte d’autres personnes
Server, Impersonate

Peut effectuer des opérations pour le compte d’autres utilisateurs ou services. Attribuez cette autorisation uniquement aux comptes de service.

Événements de déclencheur
Collection, TRIGGER_EVENT Server, TRIGGER_EVENT

Peut déclencher des événements d’alerte de projet dans la collection. Attribuez uniquement des comptes de service.

Afficher les informations de synchronisation du système Collection, SYNCHRONIZE_READ

Peut appeler les interfaces de programmation d’applications de synchronisation. Attribuez uniquement des comptes de service.

Boards

autorisations de processus Administration ister
Process, AdministerProcessPermissions

Peut modifier les autorisations pour personnaliser le suivi des travaux en créant et en personnalisant les processus hérités.

• Personnaliser un projet
• Ajouter et gérer des processus

Créer un processus
Process, Create

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.

Supprimer le champ de l’organisation
Collection, DELETE_FIELD

Peut supprimer un champ personnalisé ajouté à un processus.

Processus de suppression
Process, Delete

Peut supprimer un processus hérité utilisé pour personnaliser le suivi du travail et Azure Boards.

Processus de modification
Process, Edit

Peut modifier un processus hérité personnalisé.

Référentiels

S’applique uniquement au contrôle de version Team Foundation (TFVC)

modifications de Administration ister
VersionControlPrivileges, AdminWorkspaces

Peut supprimer des ensembles de rayons créés par d’autres utilisateurs.

espaces de travail Administration ister
Workspaces, Administer

Peut créer et supprimer des espaces de travail pour d’autres utilisateurs.

Créer un espace de travail
VersionControlPrivileges, CreateWorkspace

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

autorisations de ressource de build Administration ister
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.

Gérer les ressources de build
BuildAdministration, ManageBuildResources

Peut gérer les ordinateurs de build, les agents de build et les contrôleurs de build.

Gérer les stratégies de pipeline
BuildAdministration, ManagePipelinePolicies

Peut gérer les paramètres de pipeline définis par le biais des paramètres de l’organisation, des pipelines, des Paramètres.

Utiliser des ressources de build
BuildAdministration, UseBuildResources

Peut réserver et allouer des agents de build. Attribuez uniquement des comptes de service pour les services de build.

Afficher les ressources de build
BuildAdministration, ViewBuildResources

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

Gérer les contrôleurs de test
Collection, MANAGE_TEST_CONTROLLERS

Peut inscrire et désinscrire des contrôleurs de test.

Audit

Supprimer des flux d’audit
AuditLog, Delete_Streams

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.

Gérer les flux d’audit
AuditLog, Manage_Streams

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.

Afficher le journal d’audit
AuditLog, Read

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

Gérer les stratégies d’entreprise
Collection, MANAGE_ENTERPRISE_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.

Page active

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou de la collection, 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 et de regroupement est attribuée à tous les membres du groupe de regroupements de projets Administration istrators. 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 Administration istrators 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

autorisations de ressource de build Administration ister
BuildAdministration, AdministerBuildResourcePermissions

Peut modifier les autorisations pour les pipelines de build au niveau de la collection de projets. Cela inclut les artefacts suivants :

• 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

autorisations de processus Administration ister
Process, AdministerProcessPermissions

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 :

• Personnaliser un projet
• Ajouter et gérer des processus

modifications de Administration ister
VersionControlPrivileges, AdminWorkspaces

Peut supprimer des ensembles de rayons créés par d’autres utilisateurs. S’applique quand TFVC est utilisé comme contrôle de code source.

espaces de travail Administration ister
Workspaces, Administer

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.

Modifier les paramètres de trace
Collection, DIAGNOSTIC_TRACE

Peut modifier les paramètres de trace pour collecter des informations de diagnostic plus détaillées sur les services Web Azure DevOps.

Créer un espace de travail
VersionControlPrivileges, CreateWorkspace

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.

Créer des projets (anciennement créer des projets d’équipe)
Collection, CREATE_PROJECTS

Peut ajouter des projets à une collection de projets. Des autorisations supplémentaires peuvent être requises en fonction de votre déploiement local.

Créer un processus
Process, Create

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é.

Supprimer le processus « Processus, Supprimer »

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é.

Supprimer le projet d’équipe
Project, DELETE

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, à l’exception de la restauration de la collection à un point avant la suppression du projet.

Modifier les informations au niveau de la collection « Collection, GENERIC_WRITE »

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, les extensions et les paramètres d’ID Microsoft Entra
• 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.

Processus de modification
Process, Edit

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é.

Effectuer des demandes pour le compte d’autres personnes
Server, Impersonate

Peut effectuer des opérations pour le compte d’autres utilisateurs ou services. Attribuez cette autorisation uniquement aux comptes de service locaux.

Gérer les ressources de build
BuildAdministration, ManageBuildResources

Peut gérer les ordinateurs de build, les agents de build et les contrôleurs de build.

Gérer les stratégies d’entreprise
Collection, MANAGE_ENTERPRISE_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.

Gérer les stratégies de pipeline
BuildAdministration, ManagePipelinePolicies

Peut gérer les paramètres de pipeline définis par le biais des paramètres de l’organisation, des pipelines, des Paramètres.

Gérer le modèle de processus
Collection, MANAGE_TEMPLATE

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=.

Gérer les contrôleurs de test
Collection, MANAGE_TEST_CONTROLLERS

Peut inscrire et désinscrire des contrôleurs de test.

Événements de déclencheur
Collection, TRIGGER_EVENT Server, TRIGGER_EVENT

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 project Collection Administration istrators.

Utiliser des ressources de build
BuildAdministration, UseBuildResources

Peut réserver et allouer des agents de build. Attribuez uniquement des comptes de service pour les services de build.

Afficher les ressources de build
BuildAdministration, ViewBuildResources

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
Collection, GENERIC_READ

Peut afficher les autorisations au niveau de l’organisation pour un utilisateur ou un groupe.

Afficher les informations de synchronisation du système
Collection, SYNCHRONIZE_READ

Peut appeler les interfaces de programmation d’applications de synchronisation. Attribuez uniquement des comptes de service.

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou de la collection, 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 et de regroupement est attribuée à tous les membres du groupe de regroupements de projets Administration istrators. 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 Administration istrators 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.

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.

Page de préversion

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 à un groupe au niveau du projet est affectée à tous les membres du groupe Project Administration istrators. 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 Project Administration istrators. 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

Supprimer le projet d’équipe
Project, DELETE

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 ont accordé l’autorisation au niveau du projet peuvent être en mesure de supprimer le projet pour lequel ils ont l’autorisation. Pour vous assurer qu’un utilisateur n’est pas en mesure de supprimer un projet, veillez à définir le projet d’équipe Supprimer au niveau du projet sur Refuser également.

Modifier les informations au niveau du projet
Project, MANAGE_PROPERTIES

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 à un groupe au niveau du projet est affectée à tous les membres du groupe Project Administration istrators. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.

Gérer les propriétés du projet
Project, MANAGE_SYSTEM_PROPERTIES

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.

Renommer le projet
Project, RENAME

Peut modifier le nom 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. Cela 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 qui ont reçu les 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.

Mettre à jour la visibilité du projet
Project, UPDATE_VISIBILITY

Peut modifier la visibilité du projet de privé à public ou public en privé. S’applique uniquement à Azure DevOps Services.

Afficher les informations au niveau du projet
Project, GENERIC_READ

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, elles ne peuvent pas afficher le projet ou se connecter au projet.

Boards

Ignorer les règles sur les mises à jour des éléments de travail
Project, BYPASS_RULES

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).

Processus de modification du projet
Project, CHANGE_PROCESS

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.

Créer une définition de balise
Tagging, Create

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é. Consultez l’espace de noms de sécurité et la référence d’autorisation, Balisage.

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.

Supprimer et restaurer des éléments de travail

ou supprimer 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.

Déplacer des éléments de travail hors de ce projet
Project, WORK_ITEM_MOVE

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.

Supprimer la vue Analyse partagée
AnalyticsViews, Delete

Peut supprimer des vues Analytics qui ont été enregistrées sous la zone partagée.

Modifier la vue Analyse partagée
AnalyticsViews, Edit

Peut créer et modifier des vues d’analytique partagée.

Afficher l’analytique
AnalyticsViews, Read

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

Créer des exécutions de test
Project, PUBLISH_TEST_RESULTS

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.

Supprimer les exécutions de test
Project, DELETE_TEST_RESULTS

Peut supprimer une exécution de test.

Gérer les configurations de test
Project, MANAGE_TEST_CONFIGURATIONS

Peut créer et supprimer des configurations de test.

Gérer les environnements de test
Project, MANAGE_TEST_ENVIRONMENTS

Peut créer et supprimer des environnements de test.

Afficher les exécutions de test
Project, VIEW_TEST_RESULTS

Peut afficher les plans de test sous le chemin de la zone de projet.

Page active

Autorisation (interface utilisateur)

Namespace permission

Description

Ignorer les règles sur les mises à jour des éléments de travail
Project, BYPASS_RULES

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 où cela est utile sont des migrations où vous ne souhaitez pas mettre à jour les champs d’octet/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 à passer par le modèle objet client, en initialisant en mode contournement (initialiser WorkItemStore avec WorkItemStoreFlags.BypassRules).

Processus de modification du projet
Project, CHANGE_PROCESS

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 en savoir plus, consultez Créer et gérer des processus hérités.

Créer une définition de balise
Tagging, Create

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 des autorisations d’étiquetage supplémentaires via des outils de gestion de la sécurité. Consultez l’espace de noms de sécurité et la référence d’autorisation, Balisage.

Remarque

Tous les utilisateurs autorisés à accéder aux parties prenantes 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. 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.

Créer des exécutions de test
Project, PUBLISH_TEST_RESULTS

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.

Supprimer et restaurer des éléments de travail

ou supprimer 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. Le groupe Contributeurs a des éléments de travail Supprimer et restaurer au niveau du projet défini sur Autoriser par défaut.

Supprimer la vue Analyse partagée
AnalyticsViews, Delete

Peut supprimer des vues Analytics qui ont été enregistrées sous la zone partagée.

Supprimer un projet
Project, DELETE

Peut supprimer un projet d’une organisation ou d’une collection de projets.

Supprimer les exécutions de test
Project, DELETE_TEST_RESULTS

Peut supprimer une exécution de test.

Modifier les informations au niveau du projet Project, MANAGE_PROPERTIES

Peut modifier les autorisations au niveau du projet pour les utilisateurs et les groupes, la description du projet et la visibilité des service de projet. Peut modifier les autorisations au niveau du projet pour les utilisateurs et les groupes.

Remarque

Modifier les informations au niveau du projet inclut la possibilité d’effectuer les tâches suivantes pour le projet :

• Créer et modifier des zones et des itérations
• Modifier les stratégies d'archivage
• Modifier les requêtes d’élément de travail partagé
• Modifier les listes de contrôle d’accès d’autorisation au niveau du projet
• Gérer les modèles de processus
• Personnaliser un projet (local uniquement)
• Créer et modifier des listes globales (localement uniquement)
• Modifier les abonnements aux événements (e-mail ou SOAP) au niveau du projet
• Lorsqu’ils sont combinés avec le processus de modification de l’autorisation de projet , les utilisateurs peuvent modifier le processus d’héritage d’un projet.

Modifier la vue Analyse partagée
AnalyticsViews, Edit

Peut créer et modifier des vues d’analytique partagée.

Gérer les propriétés du projet
Project, MANAGE_SYSTEM_PROPERTIES

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.

Gérer les configurations de test
Project, MANAGE_TEST_CONFIGURATIONS

Peut créer et supprimer des configurations de test.

Gérer les environnements de test
Project, MANAGE_TEST_ENVIRONMENTS

Peut créer et supprimer des environnements de test.

Déplacer des éléments de travail hors de ce projet
Project, WORK_ITEM_MOVE

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.

Renommer le projet Project, RENAME

Peut modifier le nom 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. Cela 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 qui ont reçu les 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.

Mettre à jour la visibilité du projet
Project, UPDATE_VISIBILITY

Peut modifier la visibilité du projet de privé à public ou public en privé. S’applique uniquement à Azure DevOps Services.

Afficher l’analytique
AnalyticsViews, Read

Peut accéder aux données disponibles à partir du service Analytics. Pour plus d’informations, consultez Autorisations requises pour accéder au service Analytics.

Afficher les informations au niveau du projet
Project, GENERIC_READ

Peut afficher l’appartenance et les autorisations au niveau du projet.

Afficher les exécutions de test
Project, VIEW_TEST_RESULTS

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. Voir aussi, Qu’est-ce que les vues Analytics ? 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.

Autorisation (interface utilisateur)

Namespace permission

Description

Supprimer des vues d’analytique partagée
AnalyticsViews, Delete

Peut supprimer la vue Analyse partagée.

Modifier les vues d’analytique partagée AnalyticsViews, Edit

Peut modifier les paramètres de la vue Analyse partagée.

Afficher les vues d’analytique partagée AnalyticsViews, Read

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.

Permission Namespace permission	Description
Supprimer un tableau de bord DashboardsPrivileges, Delete	Peut supprimer le tableau de bord du projet.
Modifier le tableau de bord DashboardsPrivileges, Edit	Peut ajouter des widgets et modifier la disposition du tableau de bord du projet.
Gérer les autorisations DashboardsPrivileges, ManagePermissions	Peut gérer les autorisations pour le tableau de bord du projet.

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.

Permission Namespace permission	Description
Créer des tableaux de bord DashboardsPrivileges, Create	Peut créer un tableau de bord d’équipe.
Supprimer des tableaux de bord DashboardsPrivileges, Delete	Peut supprimer un tableau de bord d’équipe.
Modifier les tableaux de bord DashboardsPrivileges, 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.

Permission Namespace permission	Description
Supprimer un tableau de bord DashboardsPrivileges, Delete	Peut supprimer le tableau de bord d’équipe spécifique.
Modifier le tableau de bord DashboardsPrivileges, 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 Administration istrateurs de projet reçoivent toutes les autorisations de pipeline et les Administration istrateurs 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

autorisations de build Administration ister
Build, AdministerBuildPermissions

Peut administrer les autorisations de génération pour d’autres utilisateurs.

Supprimer la définition de build
Build, DeleteBuildDefinition

Peut supprimer des définitions de build pour ce projet.

Supprimer des builds
Build, DeleteBuilds

Peut supprimer une build terminée. Les builds supprimées sont conservées dans l’onglet Supprimé pendant un certain temps avant leur destruction.

Détruire des builds
Build, DestroyBuilds

Peut supprimer définitivement une build terminée.

Modifier la définition de build du pipeline
de génération
Build, EditBuildDefinition

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.

Remarque

Vous 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 autorisent uniquement Project Administration istrators à 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.

Modifier la qualité de la build
Build, EditBuildQuality

Peut ajouter des informations sur la qualité de la build via Team Explorer ou le portail web.

Gérer les qualités de build
Build, ManageBuildQualities

Peut ajouter ou supprimer des qualités de construction. S’applique uniquement aux builds XAML.

Gérer la file d’attente de build
Build, ManageBuildQueue

Peut annuler, hiérarchiser ou reporter les builds mises en file d’attente. S’applique uniquement aux builds XAML.

Remplacer la validation case activée-in par build
Build, OverrideBuildCheckInValidation

Peut valider un jeu 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.

Remarque

Attribuez la validation de remplacement case activée-in 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é.

Builds de file d’attente
Build, QueueBuilds

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.

Conserver indéfiniment
Build, RetainIndefinitely

Peut activer et désactiver l’indicateur Conserver indéfiniment 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.

Arrêter les builds
Build, StopBuilds

Peut arrêter toute build en cours, y compris les builds mises en file d’attente et démarrées par un autre utilisateur.

Mettre à jour les informations de build
Build, UpdateBuildInformation

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.

Afficher la définition de build
Build, ViewBuildDefinition

Peut afficher les définitions de build qui ont été créées pour le projet.

Afficher les builds
Build, ViewBuilds

Peut afficher les builds mises en file d’attente et terminées pour ce projet.

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 Administration istrateurs de projet reçoivent 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 case activée en remplaçant les stratégies de branche 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. S’applique à Azure DevOps Server 2019 et versions ultérieures.

Ignorer les stratégies lors de l’envoi (push)

Peut envoyer (push) à une branche sur laquelle les stratégies de branche sont activées. Lorsqu’un utilisateur disposant de cette autorisation effectue une transmission push qui remplacerait la stratégie de branche, l’envoi contourne automatiquement la stratégie de branche sans étape d’inscription ni 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. S’applique à Azure DevOps Server 2019 et versions ultérieures.

Contribuer
GitRepositories, GenericContribute

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 aux 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.

Contribuer aux demandes de tirage
GitRepositories, PullRequestContribute

Peut créer, commenter et voter sur les demandes de tirage.

Créer une branche
GitRepositories, CreateBranch

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

Lorsqu’un utilisateur crée une branche sur le serveur, il dispose d’autorisations 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 les utilisateurs peuvent ajouter de nouvelles validations au dépôt via leur branche.

Créer un référentiel
GitRepositories, CreateRepository

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.

Créer une balise
GitRepositories, CreateTag

Peut envoyer (push) des balises au référentiel.

Supprimer le référentiel GitRepositories, DeleteRepository

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.

Modifier les stratégies
GitRepositories, EditPolicies

Peut modifier des stratégies pour le référentiel et ses branches.

Exempt de l’application de la stratégie
GitRepositories, PolicyExempt

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.

Gérer les notes
GitRepositories, ManageNote

Peut envoyer (push) et modifier des notes Git.

Gérer les autorisations
GitRepositories, ManagePermissions

Peut définir des autorisations pour le référentiel.

Lecture GitRepositories, GenericRead

Peut cloner, extraire, extraire et explorer le contenu du référentiel.

Supprimer les verrous d’autres utilisateurs
GitRepositories, RemoveOthersLocks

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.

Renommer le référentiel
GitRepositories, RenameRepository

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. Project Administration istrators disposent de la plupart de ces autorisations, qui apparaissent 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

étiquettes Administration ister
VersionControlItems, LabelOther

Peut modifier ou supprimer des étiquettes créées par un autre utilisateur.

Check-in
VersionControlItems, Checkin

Peut case activée dans les éléments et réviser les commentaires de jeu de modifications validés. Les modifications en attente sont validées au niveau case activée-in.

Remarque

Envisagez d’ajouter ces autorisations à tous les utilisateurs ou groupes ajoutés manuellement qui contribuent au développement du projet ; tous les utilisateurs qui doivent pouvoir case activée et case activée des modifications, apporter une modification en attente aux éléments d’un dossier ou réviser les commentaires des ensembles de modifications validés.

Vérifier les modifications d’autres utilisateurs
VersionControlItems, CheckinOther

Peut case activée dans les modifications apportées par d’autres utilisateurs. Les modifications en attente sont validées au niveau case activée-in.

Pendez une modification dans un espace de travail serveur
VersionControlItems, PendChange

Peut case activée 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 case activée, de sorte que les utilisateurs ont également besoin de l’autorisation d’archivage pour partager leurs modifications avec l’équipe.

Remarque

Envisagez d’ajouter ces autorisations à tous les utilisateurs ou groupes ajoutés manuellement qui contribuent au développement du projet ; tous les utilisateurs qui doivent pouvoir case activée et case activée des modifications, apporter une modification en attente aux éléments d’un dossier ou réviser les commentaires des ensembles de modifications validés.

Étiquette
VersionControlItems, Label

Peut étiqueter les éléments.

Verrouillage
VersionControlItems, Lock

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 case activée’extraire un élément pour modification dans un autre espace de travail ou case activée dans les 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.

Remarque

Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui contribuent au développement du projet et qui doivent être en mesure de créer des branches privées, sauf si le projet est soumis à des pratiques de développement plus restrictives.

Fusionner
VersionControlItems, AdminProjectRights

Peut fusionner les modifications dans ce chemin d’accès.

Remarque

Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement qui contribuent au développement du projet et qui doivent pouvoir fusionner des fichiers sources, sauf si le projet est soumis à des pratiques de développement plus restrictives.

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 case activée inclus, même si un autre utilisateur case activée dans le fichier.

Remarque

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 case activée ed-in, même si un autre utilisateur case activée dans le fichier.

Annuler les modifications d’autres utilisateurs
VersionControlItems, UndoOther

Peut annuler une modification en attente apportée par un autre utilisateur.

Remarque

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 case activée ed-in, même si un autre utilisateur case activée dans le fichier.

Déverrouiller les modifications d’autres utilisateurs
VersionControlItems, UnlockOther

Peut déverrouiller les fichiers verrouillés par d’autres utilisateurs.

Remarque

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 case activée ed-in, même si un autre utilisateur case activée dans le fichier.

Chemin d’accès de zone (niveau objet)

Les autorisations de chemin d’accès de zone accordent ou limitent 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 accordent ou limitent 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 Project Administration istrators 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

Créer des nœuds enfants
CSS, CREATE_CHILDREN

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.

Supprimer ce nœud
CSS, CREATE_CHILDREN

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.

Remarque

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.

Modifier ce nœud
CSS, CREATE_CHILDREN

Peut définir des autorisations pour ce nœud et renommer des nœuds de zone.

Remarque

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.

Modifier les éléments de travail dans ce nœud
CSS, WORK_ITEM_WRITE

Peut modifier des éléments de travail dans ce nœud de zone.

Remarque

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.

Gérer les plans de test
CSS, MANAGE_TEST_PLANS

Peut modifier les propriétés du plan de test, telles que les paramètres de génération et de test.

Remarque

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.

Gérer les suites de tests
CSS, MANAGE_TEST_SUITES

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).

Remarque

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.

Afficher les autorisations pour ce nœud

Peut afficher les paramètres de sécurité d’un nœud de chemin d’accès de zone.

Afficher les éléments de travail dans ce nœud CSS, GENERIC_READ

Peut afficher, mais pas modifier, les éléments de travail dans ce nœud de zone.

Remarque

Si vous définissez les éléments de travail d’affichage dans ce nœud sur Refuser, l’utilisateur ne pourra 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 accordent ou limitent 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 Project Administration istrators 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

Créer des nœuds enfants
Iteration, CREATE_CHILDREN

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.

Remarque

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.

Supprimer ce nœud
Iteration, DELETE

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.

Remarque

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.

Modifier ce nœud
Iteration, GENERIC_WRITE

Peut définir des autorisations pour ce nœud et renommer des nœuds d’itération.

Remarque

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.

Afficher les autorisations pour ce nœud
Iteration, GENERIC_READ

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 Administration istrateurs de projet reçoivent 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.

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

Contribuer
WorkItemQueryFolders, Contribute

Peut afficher et modifier le dossier de requête ou enregistrer des requêtes dans le dossier.

Supprimer
WorkItemQueryFolders, Delete

Peut supprimer une requête ou un dossier de requête et son contenu.

Gérer les autorisations
WorkItemQueryFolders, ManagePermissions

Peut gérer les autorisations pour ce dossier de requête ou de requête.

Lire
WorkItemQueryFolders, Read

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 Administration istrateurs de projet sont autorisés à 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

Supprimer
Plan, Delete

Peut supprimer le plan sélectionné.

Edition
Plan, Edit

Peut modifier la configuration et les paramètres définis pour le plan sélectionné.

Gérer
Plan, Manage

Peut gérer les autorisations pour le plan sélectionné.

Affichage
Plan, View

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 Administration istrateurs de collection de projets sont autorisés à 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

autorisations de processus Administration ister
Process, AdministerProcessPermissions

Peut définir ou modifier les autorisations d’un processus hérité.

Processus de suppression
Process, Delete

Peut supprimer le processus hérité.

Processus de modification
Process, Edit

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.

Autorisation (interface utilisateur)

Namespace permission

Description

---

Créer une définition de balise
Tagging, Create

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.

Remarque

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.

Supprimer la définition de balise
Tagging, Delete

Peut supprimer une balise de la liste des balises disponibles pour ce projet.

Remarque

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. 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 3 jours, le système le supprime automatiquement.

Énumérer la définition de balise
Tagging, Enumerate

Peut afficher la liste des balises disponibles pour l’élément de travail dans le projet. Les utilisateurs sans cette autorisation ne disposeront pas d’une liste de balises disponibles à partir desquelles choisir dans le formulaire d’élément de travail ou dans l’éditeur de requête.

Remarque

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.

Mettre à jour la définition de balise
Tagging, Update

Peut renommer une balise à l’aide de l’API REST.

Remarque

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 Administration istrateurs de projet et les Administration istrateurs de mise en production reçoivent 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 release Administration istrator au niveau du projet est créé en même temps que le 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

autorisations de publication Administration ister

Peut modifier toutes les autres autorisations indiquées ici.

Projet, pipeline de mise en production, environnement

Créer des versions

Peut créer de nouvelles mises en production.

Projet, pipeline de mise en production

Supprimer le pipeline de mise en production

Peut supprimer le ou les pipelines de mise en production.

Projet, pipeline de mise en production

Supprimer l’environnement de mise en production

Peut supprimer des environnements dans des pipelines de mise en production.

Projet, pipeline de mise en production, environnement

Supprimer les versions

Peut supprimer les mises en production d’un pipeline.

Projet, pipeline de mise en production

Modifier le 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

Modifier l’environnement de mise en production

Peut modifier les environnements dans les 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

Gérer les déploiements

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 case activée l’autorisation de l’utilisateur qui a créé la version.

Projet, pipeline de mise en production, environnement

Gérer les approbateurs de mise en production

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

Gérer les versions

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

Afficher le pipeline de mise en production

Peut afficher le ou les pipelines de mise en production.

Projet, pipeline de mise en production

Afficher les versions

Peut afficher les mises en production appartenant au ou 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, la collection project Administration istrators, project Administration istrators et release Administration istrators reçoivent toutes les autorisations ci-dessus par défaut. Les contributeurs reçoivent toutes les autorisations, à l’exception des autorisations de mise en production Administration ister. 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 Administration istrateurs project, build et release reçoivent 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’autorisation de sécurité az devops ou des outils 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 collection de projets Administration istrateurs, ou les 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 Project Administration istrators ou des utilisateurs disposant des informations de niveau projet peuvent définir des alertes dans ce projet pour d’autres personnes ou pour une équipe.

Articles connexes

• Bien démarrer avec les autorisations, l’accès et les groupes de sécurité
• Outils de gestion de la sécurité et des autorisations
• Informations de référence sur l’espace de noms de sécurité et les autorisations pour Azure DevOps
• Comptes de service et dépendances
• Ajouter des utilisateurs à une organisation (Azure DevOps Services)
• Ajouter des utilisateurs à une équipe ou à un projet
• Ajouter des utilisateurs à un rôle d’administrateur
• Faire d’un utilisateur un administrateur d’équipe
• Résoudre les problèmes liés aux autorisations