Partager via


Informations de référence sur les groupes de sécurité, les comptes de service et les autorisations

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Cet article fournit une référence complète pour chaque utilisateur, groupe et autorisation intégré.

Pour obtenir une référence rapide aux affectations par défaut, consultez Autorisations et accès par défaut. Pour obtenir une vue d’ensemble de la façon dont les autorisations et la sécurité sont gérées, consultez À propos des autorisations, des accès et des groupes de sécurité, À propos des rôles de sécurité et des niveaux d’accès.

Pour savoir comment ajouter des utilisateurs à un groupe ou définir une autorisation spécifique que vous pouvez gérer via le portail web, consultez les ressources suivantes :


Remarque

Les images affichées dans votre portail web peuvent différer des images de cet article en raison des mises à jour système, mais la fonctionnalité de base reste la même, sauf indication explicite.

Comptes de service

Le système génère quelques comptes de service pour prendre en charge des opérations spécifiques. Le tableau suivant décrit ces comptes d’utilisateur, qui sont ajoutés au niveau de l’organisation ou du regroupement.

Nom d'utilisateur Description
Service du pool d’agents Dispose de l’autorisation d’écouter la file d’attente de messages pour que le pool spécifique reçoive le travail. Dans la plupart des cas, vous n’avez pas besoin de gérer directement les membres du groupe : le processus d’inscription de l’agent le gère pour vous. Lorsque vous inscrivez l’agent, le compte de service que vous spécifiez (généralement le service réseau) est automatiquement ajouté. Responsable de l’exécution d’opérations de lecture/écriture Azure Boards et de la mise à jour des éléments de travail lorsque les objets GitHub changent.
Azure Boards Ajouté lorsque Azure Boards est connecté à GitHub. Vous ne devez pas avoir à gérer les membres de ce groupe. Responsable de la gestion de la création de liens entre GitHub et Azure Boards.
PipelinesSDK Ajouté si nécessaire pour prendre en charge les jetons d’étendue de service de stratégie Pipelines. Ce compte d’utilisateur est similaire aux identités de service de génération, mais prend en charge le verrouillage des autorisations séparément. Dans la pratique, les jetons qui impliquent cette identité reçoivent des autorisations en lecture seule pour les ressources de pipeline et la possibilité unique d’approuver les demandes de stratégie. Ce compte doit être traité de la même façon que les identités de service de build sont traitées.
Service de génération ProjectName Dispose des autorisations nécessaires pour exécuter des services de build pour le projet et est un utilisateur hérité utilisé pour les builds XAML. Il s’agit automatiquement d’un membre du groupe de services de sécurité, qui est utilisé pour stocker les utilisateurs disposant d’autorisations, mais aucun autre groupe de sécurité.
Service de build de la collection de projets Dispose des autorisations nécessaires pour exécuter des services de génération pour la collection. Il s’agit automatiquement d’un membre du groupe de services de sécurité, qui est utilisé pour stocker les utilisateurs disposant d’autorisations, mais aucun autre groupe de sécurité.

Groupes

Vous pouvez accorder des autorisations directement à un individu ou à un groupe. L’utilisation de groupes simplifie les choses et le système fournit plusieurs groupes intégrés à cet effet. Ces groupes et les autorisations par défaut qu’ils reçoivent sont définies à différents niveaux : serveur (déploiement local uniquement), collection de projets, projet et objets spécifiques. Vous pouvez également créer vos propres groupes et leur accorder l’ensemble spécifique d’autorisations approprié pour certains rôles de votre organisation.

Remarque

Les groupes de sécurité sont gérés au niveau de l’organisation, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupe au sein d’une organisation, vous pouvez utiliser l’outil AZURE DevOps CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Remarque

Les groupes de sécurité sont gérés au niveau du regroupement, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupes au sein d’une collection, vous pouvez utiliser l’outil AZURE DevOps CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Remarque

Les groupes de sécurité sont gérés au niveau du regroupement, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupes d’une collection, vous pouvez utiliser les API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Groupes au niveau du serveur

Lorsque vous installez Azure DevOps Server, le système crée des groupes par défaut disposant d’autorisations au niveau du déploiement au niveau du serveur. Vous ne pouvez pas supprimer ou supprimer les groupes intégrés au niveau du serveur.

Capture d’écran de la boîte de dialogue Groupe de sécurité Azure DevOps.

Vous ne pouvez pas supprimer ou supprimer les groupes de niveau serveur par défaut.

Le nom complet de chacun de ces groupes est [Team Foundation]\{nom du groupe}. Par conséquent, le nom complet du groupe Administrateurs au niveau du serveur est [Team Foundation]\Team Foundation Administrators.

Nom du groupe

autorisations

Appartenance

Comptes de service Azure DevOps

Dispose d’autorisations au niveau du service pour l’instance de serveur.

Contient le compte de service fourni pendant l’installation

Ce groupe doit contenir uniquement des comptes de service et non des comptes d’utilisateur ou des groupes qui contiennent des comptes d’utilisateur. Par défaut, ce groupe est membre des administrateurs Team Foundation.

Pour ajouter un compte à ce groupe après avoir installé Azure DevOps Server, utilisez l’utilitaire TFSSecurity.exe dans le sous-dossier Outils de votre répertoire d’installation local. Utilisez la commande suivante : TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://azuredevopsservername.

Comptes de service proxy Azure DevOps

Dispose d’autorisations de niveau de service pour le proxy Azure DevOps Server et certaines autorisations au niveau du service.

Remarque

Ce compte est créé lorsque vous installez le service proxy Azure DevOps.

Ce groupe doit contenir uniquement des comptes de service et non des comptes d’utilisateur ou des groupes qui contiennent des comptes d’utilisateur.

Utilisateurs valides Azure DevOps

Dispose de l’autorisation d’afficher les informations au niveau de l’instance du serveur.

Contient tous les utilisateurs connus pour exister dans l’instance de serveur. Vous ne pouvez pas modifier l’appartenance à ce groupe.

Administrateurs Team Foundation

Dispose des autorisations nécessaires pour effectuer toutes les opérations au niveau du serveur.

Groupe Administrateurs locaux (BUILTIN\Administrators) pour n’importe quel serveur qui héberge les services d’application Azure DevOPs/Team Foundation.

Serveur \Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.

Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur les opérations au niveau du serveur.

Remarque

Si votre déploiement utilise Reporting, envisagez d’ajouter les membres de ce groupe aux groupes Gestionnaires de contenu dans Reporting Services.

Groupes au niveau de la collection

Lorsque vous créez une organisation ou une collection de projets dans Azure DevOps, le système crée des groupes au niveau du regroupement disposant d’autorisations dans cette collection. Vous ne pouvez pas supprimer ou supprimer les groupes intégrés au niveau de la collection.

Remarque

Pour activer la page d’aperçu des paramètres des autorisations des organisations v2 , consultez Activer les fonctionnalités d’aperçu. La page d’aperçu fournit une page de paramètres de groupe que la page active ne contient pas.

La page d’aperçu n’est pas disponible pour les versions locales.

Capture d’écran des groupes de regroupements Project, nouvelle interface utilisateur.

Le nom complet de chacun de ces groupes est [{nom de la collection}]\{nom du groupe}. Par conséquent, le nom complet du groupe d’administrateurs pour la collection par défaut est [Collection par défaut]\Administrateurs de collection de projets.

Nom du groupe

autorisations

Appartenance

Project Collection Administrators

Dispose des autorisations nécessaires pour effectuer toutes les opérations pour la collection.

Contient le groupe Administrateurs locaux (BUILTIN\Administrators) pour le serveur sur lequel les services de la couche Application sont installés. Contient les membres du groupe Comptes de service CollectionName/. Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur la collection.

Remarque

Si votre déploiement utilise Reporting Services, envisagez d’ajouter les membres de ce groupe aux groupes Gestionnaires de contenu Team Foundation dans Reporting Services.

Collection de projets d’administrateurs de build

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

Limitez ce groupe aux utilisateurs les plus rares qui nécessitent un contrôle administratif total sur les serveurs de build et les services pour cette collection.

Créer des comptes de service de la collection de projets

Dispose des autorisations nécessaires pour exécuter des services de génération pour la collection.

Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service. Il s’agit d’un groupe hérité utilisé pour les builds XAML. Utilisez l’utilisateur du service de génération de regroupement de projets ({votre organisation}) pour gérer les autorisations pour les builds actuelles.

Comptes de service proxy de la collection de projets

Dispose des autorisations nécessaires pour exécuter le service proxy pour la collection.

Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service.

Comptes de service de la collection de projets

Dispose des autorisations de niveau de service pour la collection et pour Azure DevOps Server.

Contient le compte de service fourni lors de l’installation. Ce groupe doit contenir uniquement des comptes de service et des groupes qui contiennent uniquement des comptes de service. Par défaut, ce groupe est membre du groupe Administrateurs.

Comptes de service test de la collection de projets

Dispose des autorisations de service de test pour la collection.

Limitez ce groupe aux comptes de service et aux groupes qui contiennent uniquement des comptes de service.

Utilisateurs valides de la collection de projets

Dispose des autorisations nécessaires pour accéder aux projets d’équipe et afficher des informations dans la collection.

Contient tous les utilisateurs et groupes ajoutés n’importe où dans la collection. Vous ne pouvez pas modifier l’appartenance à ce groupe.

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 explicitement ajoutés au projet auxquels l’utilisateur est connecté.

Ajoutez des utilisateurs à ce groupe lorsque vous souhaitez limiter leur visibilité et leur accès à ces projets auxquels vous les ajoutez explicitement. n’ajoutez pas d’utilisateurs à ce groupe s’ils sont également ajoutés au groupe Administrateurs de collection de projets.

Remarque

Le groupe Utilisateurs dans l’étendue du projet devient disponible avec un accès limité lorsque la fonctionnalité d’aperçu au niveau de l’organisation, limiter la visibilité des utilisateurs et la collaboration à des projets spécifiques est activée. Pour plus d’informations, notamment sur les appels importants liés à la sécurité, consultez Gérer votre organisation, Limiter la visibilité des utilisateurs pour les projets, etc.

Groupes de services de sécurité

Permet de stocker des utilisateurs disposant d’autorisations, mais pas d’un autre groupe de sécurité.

N’affectez pas d’utilisateurs à ce groupe. Si vous supprimez des utilisateurs de tous les groupes de sécurité, vérifiez si vous devez les supprimer de ce groupe.

Groupes au niveau du projet

Pour chaque projet que vous créez, le système crée les groupes de niveau projet suivants. Ces groupes reçoivent des autorisations au niveau du projet.

Remarque

Pour activer la page d’aperçu de la page Paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.

La page d’aperçu n’est pas disponible pour les versions locales.

Capture d’écran des groupes et autorisations au niveau du projet, version préliminaire d’Azure DevOps.

Conseil

Le nom complet de chacun de ces groupes est [{nom du projet}]\{nom du groupe}. Par exemple, le groupe contributeurs d’un projet appelé « Mon projet » est [Mon projet]\Contributeurs.

Nom du groupe

autorisations

Appartenance

Administrateurs de build

Dispose des autorisations nécessaires pour administrer les ressources de build et les autorisations de génération pour le projet. Les membres peuvent gérer des environnements de test, créer des exécutions de test et gérer des builds.

Affecter aux utilisateurs qui définissent et gèrent des pipelines de build.

Contributeurs

Dispose des autorisations nécessaires pour contribuer entièrement à la base de code du projet et au suivi des éléments de travail. Les autorisations principales qu’ils n’ont pas sont des autorisations qui gèrent ou administrent des ressources.

Par défaut, le groupe d’équipe créé lorsque vous créez un projet est ajouté à ce groupe, et tout utilisateur que vous ajoutez à l’équipe ou au projet est membre de ce groupe. En outre, toute équipe que vous créez pour un projet est ajoutée à ce groupe.

Lecteurs

Dispose des autorisations nécessaires pour afficher les informations du projet, la base de code, les éléments de travail et d’autres artefacts, mais pas les modifier.

Attribuez aux membres de votre organisation ou collection qui souhaitent fournir des autorisations d’affichage uniquement à un projet. Ces utilisateurs peuvent afficher les backlogs, les tableaux de bord, etc., mais pas ajouter ou modifier quoi que ce soit.

Administrateurs de projet

Dispose des autorisations nécessaires pour administrer tous les aspects des équipes et des projets, même s’ils ne peuvent pas créer de projets d’équipe.

Affecter aux utilisateurs qui ont besoin des fonctions suivantes : gérer les autorisations des utilisateurs, créer ou modifier des équipes, modifier les paramètres d’équipe, définir des chemins d’accès à la zone ou à l’itération ou personnaliser le suivi des éléments de travail. Les membres du groupe Administrateurs de projet disposent des autorisations nécessaires pour effectuer les tâches suivantes :

  • Ajouter et supprimer des utilisateurs de l’appartenance au projet
  • Ajouter et supprimer des groupes de sécurité personnalisés d’un projet
  • Ajouter et administrer toutes les équipes de projet et fonctionnalités associées à l’équipe
  • Modifier les listes de contrôle d’accès d’autorisation au niveau du projet
  • Modifiez les abonnements aux événements (e-mail ou SOAP) pour les équipes ou les événements au niveau du projet.

Utilisateurs valides du projet

Dispose des autorisations d’accès et d’affichage des informations de projet.

Contient tous les utilisateurs et groupes ajoutés n’importe où au projet. Vous ne pouvez pas modifier l’appartenance à ce groupe.

Remarque

Nous vous recommandons de ne pas modifier les autorisations par défaut pour ce groupe.

Administrateurs de mise en production

Dispose des autorisations nécessaires pour gérer toutes les opérations de mise en production.

Affecter aux utilisateurs qui définissent et gèrent des pipelines de mise en production.

Remarque

Le groupe Administrateur de mise en production est créé en même temps que le premier pipeline de mise en production est défini. Elle n’est pas créée par défaut lorsque le projet est créé.

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 ont également un groupe créé pour eux et ajoutés au groupe Contributeurs.

Ajoutez des membres de l’équipe à ce groupe. Pour accorder l’accès pour configurer les paramètres d’équipe, ajoutez un membre de l’équipe au rôle d’administrateur d’équipe.

Rôle d’administrateur d’équipe

Pour chaque équipe que vous ajoutez, vous pouvez affecter un ou plusieurs membres d’équipe en tant qu’administrateurs. Le rôle d’administrateur d’équipe n’est pas un groupe avec un ensemble d’autorisations définies. Au lieu de cela, le rôle d’administrateur d’équipe est chargé de gérer les ressources d’équipe. Pour plus d’informations, consultez Gérer les équipes et configurer les outils d’équipe. Pour ajouter un utilisateur en tant qu’administrateur d’équipe, consultez Ajouter un administrateur d’équipe.

Remarque

Les administrateurs de projet peuvent gérer toutes les zones administratives d’équipe pour toutes les équipes.

autorisations

Le système gère les autorisations à différents niveaux (organisation, projet, objet et autorisations basées sur des rôles) et les affecte par défaut à un ou plusieurs groupes intégrés. Vous pouvez gérer la plupart des autorisations via le portail web. Gérez davantage d’autorisations avec l’outil en ligne de commande (CLI) .

Le système gère les autorisations à différents niveaux ( serveur, collection, projet, objet et autorisations basées sur des rôles) et les affecte par défaut à un ou plusieurs groupes intégrés. Vous pouvez gérer la plupart des autorisations via le portail web. Gérez davantage d’autorisations avec l’outil en ligne de commande (CLI) .

Dans les sections suivantes, l’autorisation d’espace de noms est fournie en suivant l’étiquette d’autorisation qui s’affiche dans l’interface utilisateur. Par exemple :
Créer une définition de balise
Tagging, Create

Pour plus d’informations, consultez Espace de noms de sécurité et la référence d’autorisation.

Autorisations au niveau du serveur

Gérez les autorisations au niveau du serveur via l’outil en ligne de commande Team Foundation Administration Console ou TFSSecurity. Les administrateurs Team Foundation bénéficient de toutes les autorisations au niveau du serveur. D’autres groupes au niveau du serveur ont sélectionné des attributions d’autorisations.

Capture d’écran des autorisations au niveau du serveur.

Autorisation (interface utilisateur)
Namespace permission

Description


Administrer l’entrepôt

Warehouse, Administer

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.

Créer une collection de projets

CollectionManagement, CreateCollection

Peut créer et administrer des collections.

Supprimer la collection de projets

CollectionManagement, DeleteCollection

Peut supprimer un regroupement du déploiement.

Remarque

La suppression d’une collection ne supprime pas la base de données de collecte de SQL Server.

Modifier les informations au niveau de l’instance

Server, GenericWrite

Peut modifier les autorisations au niveau du serveur pour les utilisateurs et les groupes, et ajouter ou supprimer des groupes de niveau serveur de la collection.

Remarque

Modifier les informations au niveau de l’instance inclut la possibilité d’effectuer ces tâches définies dans toutes les collections définies pour l’instance :

  • Modifier les paramètres Extensions et Analytics
  • Permet implicitement à l’utilisateur de modifier les autorisations de contrôle de version et les paramètres du référentiel
  • Modifier les abonnements ou alertes d’événements pour les notifications globales, au niveau du projet et les événements au niveau de l’équipe
  • Modifier tous les paramètres de projet et de niveau équipe pour les projets définis dans les collections
  • Créer et modifier des listes globales

Pour accorder toutes ces autorisations à une invite de commandes, vous devez utiliser la tf.exe Permission commande pour accorder les autorisations et AdminConnections les AdminConfiguration autorisations en plus de GENERIC_WRITE.

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 uniquement des comptes de service.

Événements de déclencheur

Server, TriggerEvent

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.

Utiliser des fonctionnalités d’accès web complètes

Peut utiliser toutes les fonctionnalités du portail web local. Cette autorisation est déconseillée avec Azure DevOps Server 2019 et versions ultérieures.

Remarque

Si l’autorisation Utiliser les fonctionnalités d’accès web complète est définie sur Refuser, l’utilisateur voit uniquement ces fonctionnalités autorisées pour le groupe parties prenantes (voir Modifier les niveaux d’accès). Un refus remplace toute autorisation implicite, même pour les comptes membres de groupes d’administration tels que les administrateurs Team Foundation.

Afficher les informations au niveau de l’instance

Server, GenericRead

Peut afficher l’appartenance au groupe au niveau du serveur et les autorisations de ces utilisateurs.

Remarque

L’autorisation Afficher les informations au niveau de l’instance est également affectée au groupe Utilisateurs valides Azure DevOps.

Autorisations au niveau de l’organisation

Gérez les autorisations au niveau de l’organisation via le contexte d’administration du portail web ou avec les commandes az devops security group. Les administrateurs de collection de projets reçoivent toutes les autorisations au niveau de l’organisation. D’autres groupes au niveau de l’organisation ont des attributions d’autorisations sélectionnées.

Remarque

Pour activer la page d’aperçu de la page Paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.

Capture d’écran des autorisations et groupes au niveau de l’organisation, Azure DevOps Services.

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou des regroupements, d’ajouter et de gérer l’appartenance à un groupe au niveau de l’organisation ou du regroupement, et de modifier les listes de contrôle d’accès d’autorisation au niveau du projet est attribuée à tous les membres du groupe Administrateurs de regroupement de projets. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.

Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de collection de projets. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.

Autorisation (interface utilisateur)

Namespace permission

Description

Généralités

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 et les extensions
  • Modifier les autorisations de contrôle de version et les paramètres du référentiel
  • Modifier les abonnements ou alertes d’événements pour les notifications globales, au niveau du projet et les événements au niveau de l’équipe
  • Modifier tous les paramètres de projet et de niveau équipe pour les projets définis dans les collections

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

Administrer les autorisations de processus
Process, AdministerProcessPermissions

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

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

Processus de suppression
Process, Delete

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)

Administrer les changements enregistrés
VersionControlPrivileges, AdminWorkspaces

Administrer des espaces de travail
Workspaces, Administer

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

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 :

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.

Autorisations au niveau de la collection

Gérez les autorisations au niveau de la collection via le contexte d’administrateur du portail web ou l’outil en ligne de commande TFSSecurity. Les administrateurs de collection de projets reçoivent toutes les autorisations au niveau du regroupement. D’autres groupes au niveau de la collection ont des affectations d’autorisations sélectionnées.

Les autorisations disponibles pour Azure DevOps Server 2019 et versions ultérieures varient en fonction du modèle de processus configuré pour la collection. Pour obtenir une vue d’ensemble des modèles de processus, consultez Personnaliser le suivi du travail.

Modèle de processus hérité

Modèle de processus XML local


Capture d’écran des autorisations au niveau de la collection, localement, modèle de processus hérité.

Capture d’écran des autorisations au niveau de la collection, du modèle de processus XML local local.

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau de l’organisation ou des regroupements, d’ajouter et de gérer l’appartenance à un groupe au niveau de l’organisation ou du regroupement, et de modifier les listes de contrôle d’accès d’autorisation au niveau du projet est attribuée à tous les membres du groupe Administrateurs de regroupement de projets. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.

Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de collection de projets. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.

Autorisation (interface utilisateur)

Namespace permission

Description


Administrer les autorisations de ressources de build
BuildAdministration, AdministerBuildResourcePermissions

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

Administrer les autorisations de processus
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 :

Administrer les changements enregistrés
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.

Administrer des espaces de travail
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é.

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.

Remarque

La suppression d’un projet supprime toutes les données associées au projet. Vous ne pouvez pas annuler la suppression d’un projet, à l’exception de la restauration de la collection à un point avant la suppression du projet.

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.

Remarque

Cette autorisation est valide uniquement pour Azure DevOps Services. Bien qu’il apparaisse localement pour Azure DevOps Server, il ne s’applique pas aux serveurs locaux.

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 les administrateurs de collection de projets.

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

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.

Autorisations au niveau du projet

Important

Pour accéder aux ressources au niveau du projet, l’autorisation Afficher les informations au niveau du projet doit être définie sur Autoriser. Cette autorisation porte toutes les autres autorisations au niveau du projet.

Gérez les autorisations au niveau du projet via le contexte d’administration du portail web ou avec les commandes az devops security group. Les administrateurs de projet disposent de toutes les autorisations au niveau du projet. D’autres groupes au niveau du projet ont des attributions d’autorisations sélectionnées.

Remarque

Pour activer la page d’aperçu de la page Paramètres des autorisations du projet , consultez Activer les fonctionnalités d’aperçu.

Gérez les autorisations au niveau du projet via le contexte d’administration du portail web. Les administrateurs de projet disposent de toutes les autorisations au niveau du projet. D’autres groupes au niveau du projet ont des attributions d’autorisations sélectionnées.

La page d’aperçu n’est pas disponible pour les versions locales.

Capture d’écran de la boîte de dialogue Autorisations au niveau du projet, page d’aperçu d’Azure DevOps Services.

Important

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau du projet et d’ajouter et de gérer l’appartenance au groupe au niveau du projet est affectée à tous les membres du groupe Administrateurs de projet. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.

Vous ne pouvez pas modifier les autorisations pour le groupe Administrateurs de projet. En outre, si vous pouvez modifier les attributions d’autorisations d’un membre de ce groupe, leurs autorisations effectives sont toujours conformes aux autorisations affectées au groupe d’administrateurs pour lequel ils sont membres.

Autorisation (interface utilisateur)

Namespace permission

Description

Généralités

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 autorisés au niveau du projet peuvent probablement supprimer le projet pour lequel ils disposent d’autorisations. Pour vous assurer qu’un utilisateur ne peut pas supprimer un projet, veillez également à définir le projet d’équipe Supprimer au niveau du projet sur Refuser .

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.

Remarque

L’autorisation d’ajouter ou de supprimer des groupes de sécurité au niveau du projet et d’ajouter et de gérer l’appartenance au groupe au niveau du projet est affectée à tous les membres du groupe Administrateurs de projet. Elle n’est pas contrôlée par des autorisations exposées dans l’interface utilisateur.


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

Supprimer les notifications pour les mises à jour d’éléments de travail

Project, SUPPRESS_NOTIFICATIONS

Les utilisateurs disposant de cette autorisation peuvent mettre à jour des éléments de travail sans générer de notifications. Cette fonctionnalité est utile lorsque vous effectuez des migrations de mises à jour en bloc par des outils et que vous souhaitez ignorer la génération de notifications.

Envisagez d’accorder cette autorisation aux comptes de service ou aux utilisateurs disposant des règles de contournement sur l’autorisation de mise à jour des éléments de travail. Vous pouvez définir le paramètre sur le paramètre true lors de la suppressNotifications mise à jour via des éléments de travail - mettre à jour l’API REST.

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, elle ne peut pas afficher le projet ni 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é. Pour plus d’informations, consultez l’espace de noms de sécurité et la référence d’autorisation, Étiquetage.

Remarque

Tous les utilisateurs ont accordé l’accès aux parties prenantes pour un projet privé ne peuvent ajouter que des balises existantes. Même si l’autorisation Créer une définition de balise est définie sur Autoriser, les parties prenantes ne peuvent pas ajouter de balises. Cela fait partie des paramètres d’accès des parties prenantes. Par défaut, les utilisateurs d’Azure DevOps Services ont accordé l’accès des parties prenantes pour un projet public. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.
Bien que l’autorisation Créer une définition de balise s’affiche dans les paramètres de sécurité au niveau du projet, les autorisations de balisage sont en fait des autorisations au niveau du regroupement qui sont délimitées au niveau du projet lorsqu’elles apparaissent dans l’interface utilisateur. Pour étendre les autorisations d’étiquetage à un seul projet lors de l’utilisation de la commande TFSSecurity , vous devez fournir le GUID du projet dans le cadre de la syntaxe de commande. Sinon, votre modification s’applique à l’ensemble de la collection. Gardez cela à l’esprit lors de la modification ou de la définition de ces autorisations.

Supprimez et restaurez des éléments de travail ou supprimez des éléments de travail dans ce projet.
Project, WORK_ITEM_DELETE

Peut marquer les éléments de travail dans le projet comme supprimés. Par défaut, les utilisateurs d’Azure DevOps Services ont accordé l’accès des parties prenantes pour un projet public.

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

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

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.

Capture d’écran de la boîte de dialogue de sécurité de l’affichage Analyse partagée, modification des autorisations pour un utilisateur.

Capture d’écran de la boîte de dialogue Gérer la sécurité de l’affichage Shared Analytics, modifier les autorisations d’un utilisateur, Azure DevOps Server.

Les autorisations suivantes sont définies pour chaque vue Analyse partagée. Tous les utilisateurs valides reçoivent automatiquement toutes les autorisations pour gérer les vues Analytics. Envisagez d’accorder des autorisations de sélection à des vues partagées spécifiques à d’autres membres de l’équipe ou à un groupe de sécurité que vous créez. Pour plus d’informations, consultez Présentation des vues Analytics et informations de référence sur l’espace de noms et l’autorisation De sécurité.

Autorisation (interface utilisateur)

Namespace permission

Description


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

Capture d’écran de la boîte de dialogue Autorisations du tableau de bord Project.

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.

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

Capture d’écran de la boîte de dialogue Autorisations 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

Capture d’écran de la boîte de dialogue Autorisations du tableau de bord d’équipe individuelle.

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

Capture d’écran de la boîte de dialogue de sécurité au niveau de l’objet de pipeline, cloud.

Capture d’écran de la boîte de dialogue Autorisations au niveau de l’objet 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


Administrer les autorisations de génération
Build, AdministerBuildPermissions

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

Créer un pipeline de build Build, CreateBuildPipeline

Peut créer des lignes de pipeline et modifier ces pipelines.

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 le pipeline de build
Modifier la définition de build
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.

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 de l’archivage par build
Build, OverrideBuildCheckInValidation

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.

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

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

Remarque

  • Désactivez l’héritage pour une définition de build lorsque vous souhaitez contrôler les autorisations pour des définitions de build spécifiques.
    • Lorsque l’héritage est Activé, la définition de build respecte les autorisations de génération définies au niveau du projet ou d’un groupe ou d’un utilisateur. Par exemple, un groupe Gestionnaires de build personnalisé dispose d’autorisations définies pour mettre manuellement en file d’attente une build pour le projet Fabrikam. Toute définition de build avec héritage Activé pour le projet Fabrikam permet à un membre du groupe Gestionnaires de build de mettre manuellement en file d’attente une build.
    • Toutefois, en désactivant l’héritage pour le projet Fabrikam, vous pouvez définir des autorisations qui permettent uniquement aux administrateurs de projet de mettre manuellement en file d’attente une build pour une définition de build spécifique. Cela me permettrait ensuite de définir des autorisations pour cette définition de build spécifiquement.
  • Attribuez la validation de la validation de remplacement par l’autorisation de build uniquement aux comptes de service pour les services de build et aux administrateurs de build qui sont responsables de la qualité du code. S’applique aux builds d’archivage contrôlé TFVC. Cela ne s’applique pas aux builds pr. Pour plus d’informations, consultez Archiver dans un dossier contrôlé par un processus de création d’archivage contrôlé.

Référentiel Git (au niveau de l’objet)

Gérez la sécurité de chaque dépôt ou branche Git à partir du portail web, de l’outil en ligne de commande TF ou de l’outil en ligne de commande TFSSecurity. Les administrateurs de projet bénéficient de la plupart de ces autorisations (qui s’affichent uniquement pour un projet configuré avec un dépôt Git). Vous pouvez gérer ces autorisations pour tous les dépôts Git ou pour un référentiel Git spécifique.

Capture d’écran de la boîte de dialogue Autorisations du référentiel Git.

Remarque

Définissez les autorisations sur tous les référentiels Git en apportant des modifications à l’entrée de référentiels Git de niveau supérieur. Les dépôts individuels héritent des autorisations de l’entrée de référentiels Git de niveau supérieur. Les branches héritent des autorisations des affectations effectuées au niveau du référentiel. Par défaut, les groupes Lecteurs au niveau du projet disposent uniquement d’autorisations de lecture.

Pour gérer les autorisations de dépôt et de branche Git, consultez Définir des autorisations de branche.

Autorisation (interface utilisateur)

Namespace permission

Description


Contourner les stratégies lors de la fin des demandes de tirage
GitRepositories, PullRequestBypassPolicy

Vous pouvez choisir de remplacer les stratégies de branche en vérifiant les stratégies de branche de remplacement et en activant la fusion lors de la fin d’une demande de tirage.

Remarque

Ignorez les stratégies lors de la fin des demandes de tirage et des stratégies de contournement lors de l’envoi (push) du remplacement exempt de l’application de stratégie.

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 permission effectue un push qui remplacerait la stratégie de la branche, le push contourne automatiquement la stratégie de la branche sans étape d'acceptation ou d'avertissement.

Remarque

Ignorez les stratégies lors de la fin des demandes de tirage et des stratégies de contournement lors de l’envoi (push) du remplacement exempt de l’application de stratégie.

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 à de nouvelles branches. Ne remplace pas les restrictions en place à partir des stratégies de branche.

Au niveau de la branche, vous pouvez envoyer (push) leurs modifications à la branche et verrouiller la branche. Le verrouillage d’une branche bloque les nouvelles validations d’autres utilisateurs et empêche d’autres utilisateurs de modifier l’historique de validation existant.

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

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.

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

Capture d’écran de la boîte de dialogue Autorisations TFVC.

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

Autorisation (interface utilisateur)

Namespace permission

Description


Administrer des étiquettes
VersionControlItems, LabelOther

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

Check-in
VersionControlItems, Checkin

Peut archiver les éléments et réviser les commentaires de l’ensemble de modifications validés. Les modifications en attente sont validées lors de l’archivage.*

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

Peut archiver les modifications apportées par d’autres utilisateurs. Les modifications en attente sont validées lors de l’archivage.

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

Peut extraire et apporter une modification en attente aux éléments d’un dossier. Parmi les exemples de modifications en attente, citons l’ajout, la modification, le changement de nom, la suppression, la suppression, la création de branchements et la fusion d’un fichier. Les modifications en attente doivent être vérifiées. Les utilisateurs doivent donc également disposer de l’autorisation d’archivage pour partager leurs modifications avec l’équipe.*

Étiquette
VersionControlItems, Label

Peut étiqueter les éléments.

Serrure
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 l’extraction d’un élément pour modification dans un autre espace de travail ou la vérification des modifications en attente d’un élément à partir d’un autre espace de travail. Pour plus d’informations, consultez commande Lock.

Gérer la branche
VersionControlItems, ManageBranch

Peut convertir n’importe quel dossier sous ce chemin d’accès en branche, et effectuer également les actions suivantes sur une branche : modifier ses propriétés, le réparer et le convertir en dossier. Les utilisateurs disposant de cette autorisation peuvent brancher cette branche uniquement s’ils disposent également de l’autorisation Fusion pour le chemin cible. Les utilisateurs ne peuvent pas créer de branches à partir d’une branche pour laquelle ils n’ont pas l’autorisation Gérer la branche.

Gérer les autorisations
VersionControlItems, AdminProjectRights

Peut gérer les autorisations d’autres utilisateurs pour les dossiers et les fichiers dans le contrôle de version.*

Fusionner
VersionControlItems, AdminProjectRights

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

Lire
VersionControlItems, Read

Peut lire le contenu d’un fichier ou d’un dossier. Si un utilisateur dispose d’autorisations de lecture pour un dossier, l’utilisateur peut voir le contenu du dossier et les propriétés des fichiers qu’il contient, même si l’utilisateur n’a pas l’autorisation d’ouvrir les fichiers.

Réviser les modifications des autres utilisateurs
VersionControlItems, ReviseOther

Peut modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.*

Annuler les modifications d’autres utilisateurs
VersionControlItems, UndoOther

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

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

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

* Envisagez d’ajouter cette autorisation à tous les utilisateurs ou groupes ajoutés manuellement chargés de superviser ou de surveiller le projet et qui peuvent ou doivent modifier les commentaires sur les fichiers archivés, même si un autre utilisateur a archivé le fichier.

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

Les autorisations de chemin d’accès de zone gèrent l’accès aux branches de la hiérarchie de zones et aux éléments de travail dans ces zones. Gérez la sécurité de chaque chemin d’accès de zone à partir du portail web ou à l’aide de l’outil en ligne de commande TFSSecurity. Les autorisations de zone gèrent l’accès pour créer et gérer des chemins d’accès de zone, ainsi que créer et modifier des éléments de travail définis sous les chemins d’accès de zone.

Les membres du groupe Administrateurs de projet sont automatiquement autorisés à gérer les chemins d’accès de zone d’un projet. Envisagez d’accorder aux administrateurs d’équipe ou aux responsables d’équipe des autorisations pour créer, modifier ou supprimer des nœuds de zone.

Remarque

Plusieurs équipes peuvent contribuer à un projet. Lorsque c’est le cas, vous pouvez configurer des équipes associées à une zone. Les autorisations pour les éléments de travail de l’équipe sont affectées en affectant des autorisations à la zone. Il existe d’autres paramètres d’équipe qui configurent les outils de planification agile de l’équipe.

Capture d’écran de la boîte de dialogue Autorisations de chemin d’accès de zone.

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.

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.

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.

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.

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

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 l’affichage des éléments de travail dans ce nœud sur Refuser, l’utilisateur ne peut pas voir d’éléments de travail dans ce nœud de zone. Un refus remplace toute autorisation implicite, même pour les utilisateurs membres d’un groupe d’administration.

Chemin d’itération (au niveau de l’objet)

Les autorisations de chemin d’itération gèrent l’accès pour créer et gérer des chemins d’itération, également appelés sprints.

Gérez la sécurité de chaque chemin d’itération à partir du portail web ou à l’aide de l’outil en ligne de commande TFSSecurity.

Les membres du groupe Administrateurs de projet reçoivent automatiquement ces autorisations pour chaque itération définie pour un projet. Envisagez d’accorder des autorisations aux administrateurs d’équipe, aux maîtres d’équipe ou à l’équipe pour créer, modifier ou supprimer des nœuds d’itération.

Capture d’écran de la boîte de dialogue Autorisations de chemin 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.

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.

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.

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 administrateurs de projet bénéficient de toutes ces autorisations. Les contributeurs reçoivent uniquement des autorisations en lecture.

Capture d’écran de la boîte de dialogue Autorisations des dossiers de requête.

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 administrateurs de projet disposent de toutes les autorisations nécessaires pour créer, modifier et gérer des plans. Les utilisateurs valides disposent des autorisations d’affichage (en lecture seule).

Autorisation (interface utilisateur)

Namespace permission

Description


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 administrateurs de collection de projets disposent de toutes les autorisations nécessaires pour créer, modifier et gérer des processus. Les utilisateurs valides disposent des autorisations d’affichage (en lecture seule).

Autorisation (interface utilisateur)

Namespace permission

Description


Administrer les autorisations de processus
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.

Vous pouvez gérer les autorisations d’étiquetage à l’aide de l’outil en ligne de commande TFSSecurity. Les contributeurs peuvent ajouter des balises à des éléments de travail et les utiliser pour filtrer rapidement un backlog, un tableau ou une vue des résultats de requête.

Autorisation (interface utilisateur)

Namespace permission

Description


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.

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.

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.

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

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

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

Cette autorisation n’apparaît pas dans l’interface utilisateur. Il ne peut être défini qu’à l’aide d’un outil en ligne de commande.

Release (au niveau de l’objet)

Gérez les autorisations pour chaque version définie dans le portail web. Les administrateurs de projet et les administrateurs de mise en production bénéficient de toutes les autorisations de gestion des mises en production. Ces autorisations fonctionnent dans un modèle hiérarchique au niveau du projet, pour un pipeline de mise en production spécifique ou pour un environnement spécifique dans un pipeline de mise en production. Dans cette hiérarchie, les autorisations peuvent être héritées du parent ou remplacées.

Capture d’écran montrant les autorisations au niveau de l’objet Releases.

Remarque

Le groupe de l’administrateur de mise en production au niveau du projet est créé lorsque vous définissez votre premier pipeline de mise en production.

En outre, vous pouvez affecter des approbateurs à des étapes spécifiques dans un pipeline de mise en production pour vous assurer que les applications déployées répondent aux normes de qualité.

Les autorisations suivantes sont définies dans Release Management. La colonne d’étendue explique si l’autorisation peut être définie au niveau du projet, du pipeline de mise en production ou de l’environnement.

Permission

Description

Étendues


Administrer les autorisations de mise en production

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 des 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 des environnements dans des pipelines de mise en production. Pour enregistrer les modifications apportées au pipeline de mise en production, l’utilisateur a également besoin de l’autorisation Modifier le pipeline de mise en production. Cette autorisation contrôle également si un utilisateur peut modifier la configuration à l’intérieur de l’environnement d’une instance de mise en production spécifique. Il doit aussi disposer de l’autorisation Gérer les mises en production pour pouvoir enregistrer la mise en production modifiée.

Projet, pipeline de mise en production, environnement

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 vérifier 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 les pipelines de mise en production.

Projet, pipeline de mise en production

Afficher les versions

Peut afficher les versions appartenant aux pipelines de mise en production.

Projet, pipeline de mise en production

Les valeurs par défaut de toutes ces autorisations sont définies pour les collections de projets d’équipe et les groupes de projets. Par exemple, les administrateurs de collection de projets, les administrateurs de projet et les administrateurs de mise en production reçoivent toutes les autorisations ci-dessus par défaut. Les contributeurs reçoivent toutes les autorisations, sauf Administrer les autorisations de mise en production. Les lecteurs, par défaut, sont refusés à toutes les autorisations, à l’exception du pipeline de mise en production d’affichage et des versions d’affichage.

Autorisations du groupe de tâches (build et mise en production)

Gérez les autorisations pour les groupes de tâches à partir du hub Build et Release du portail web. Les administrateurs de projet, de build et de mise en production disposent de toutes les autorisations. Les autorisations des groupes de tâches suivent un modèle hiérarchique. Les valeurs par défaut de toutes les autorisations peuvent être définies au niveau du projet et peuvent être remplacées sur une définition de groupe de tâches individuelle.

Utilisez des groupes de tâches pour encapsuler une séquence de tâches déjà définie dans une build ou une définition de mise en production dans une tâche réutilisable unique. Définissez et gérez des groupes de tâches dans l’onglet Groupes de tâches du hub build et release .

Autorisation Description
Administrer les autorisations des groupes de tâches Peut ajouter et supprimer des utilisateurs ou des groupes à la sécurité du groupe de tâches.
Supprimer le groupe de tâches Peut supprimer un groupe de tâches.
Modifier le groupe de tâches Peut créer, modifier et supprimer un groupe de tâches.

Notifications ou alertes

Aucune autorisation d’interface utilisateur n’est associée à la gestion des Notifications par e-mail ou des alertes. Au lieu de cela, vous pouvez les gérer à l’aide de l’outil en ligne de commande TFSSecurity .

  • Par défaut, les membres du groupe Contributeurs au niveau du projet peuvent s’abonner aux alertes pour eux-mêmes.
  • Les membres du groupe Administrateurs de collection de projets ou utilisateurs disposant des informations de niveau collection Modifier peuvent définir des alertes dans cette collection pour d’autres personnes ou pour une équipe.
  • Les membres du groupe Administrateurs de projet ou les utilisateurs qui ont les informations de niveau projet modifier peuvent définir des alertes dans ce projet pour d’autres personnes ou pour une équipe.

Vous pouvez gérer les autorisations d’alerte à l’aide de TFSSecurity.

TFSSecurity Action

Espace de noms TFSSecurity

Description

Administrateurs de collection de projets &
Comptes de service de collecte de projets


CREATE_SOAP_SUBSCRIPTION

EventSubscription

Peut créer un abonnement de service web basé sur SOAP.

✔️

GENERIC_READ

EventSubscription

Peut afficher les événements d’abonnement définis pour un projet.

✔️

GENERIC_WRITE

EventSubscription

Peut créer des alertes pour d’autres utilisateurs ou pour une équipe.

✔️

UNSUBSCRIBE

EventSubscription

Peut se désabonner d’un abonnement aux événements.

✔️