Appliquer des règles aux états de workflow (processus d’héritage)
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Après avoir ajouté ou modifié les états de votre flux de travail pour un type d’élément de travail, vous pouvez définir une ou plusieurs règles qui sont appliquées en fonction du changement d’état du flux de travail. L’ajout de règles aux états de workflow prend en charge les scénarios suivants :
- Prise en charge d’un processus d’approbation
- Empêcher les utilisateurs non autorisés de définir un état non valide
- Rendre un champ obligatoire ou en lecture seule ou une autre valeur en fonction des changements d’état
- Restreindre la transition d’un état à un autre
- Restreindre ou autoriser les transitions d’état à des utilisateurs ou groupes spécifiques
- Gérer un processus de flux de travail contrôlé pour prendre en charge les exigences d’audit
- Automatiser la fermeture des éléments de travail parents
- Prise en charge d’un processus d’approbation
- Empêcher les utilisateurs non autorisés de définir un état non valide
- Rendre un champ obligatoire ou en lecture seule ou une autre valeur en fonction des changements d’état
- Restreindre la transition d’un état à un autre
- Automatiser la fermeture des éléments de travail parents
- Prise en charge d’un processus d’approbation
- Rendre un champ obligatoire ou en lecture seule ou une autre valeur en fonction des changements d’état
- Automatiser la fermeture des éléments de travail parents
Consultez cet article pour comprendre comment définir des règles qui s’appliquent lorsque vous modifiez l’état d’un flux de travail.
- Comprendre les types de règles de flux de travail
- Limites d’état et de règle de flux de travail et meilleures pratiques
- Définir une valeur de champ ou rendre un champ en lecture seule ou obligatoire en fonction de la sélection d’état
- Restreindre les transitions d'état
- Restreindre ou autoriser les transitions d’état à des utilisateurs ou groupes spécifiques
- Automatiser les transitions d’état des éléments de travail parents
- Comprendre les types de règles de flux de travail
- Limites d’état et de règle de flux de travail et meilleures pratiques
- Définir une valeur de champ ou rendre un champ en lecture seule ou obligatoire en fonction de la sélection d’état
- Restreindre les transitions d'état
- Automatiser les transitions d’état des éléments de travail parents
- Comprendre les types de règles de flux de travail
- Limites d’état et de règle de flux de travail et meilleures pratiques
- Définir une valeur de champ ou rendre un champ en lecture seule ou obligatoire en fonction de la sélection d’état
- Automatiser les transitions d’état des éléments de travail parents
Important
Cet article s’applique aux versions Azure DevOps Services et Azure DevOps Server 2019 et ultérieures. Pour personnaliser un projet défini sur une collection pour TFS 2018 ou une version antérieure, consultez Modèle de processus XML local.
Important
Vous pouvez uniquement utiliser le modèle de processus d’héritage pour les projets définis sur une collection de projets configurée pour prendre en charge le modèle de processus d’héritage. Si votre collection locale est configurée pour utiliser le modèle de processus XML local, vous pouvez uniquement utiliser ce modèle de processus pour personnaliser l’expérience de suivi du travail. Pour plus d’informations, consultez Personnaliser le suivi du travail, Choisir le modèle de processus pour votre collection de projets.
Pour personnaliser un projet défini sur une collection pour TFS 2018 ou une version antérieure, consultez Modèle de processus XML local.
Règles de flux de travail
Le tableau suivant indique les trois groupes de règles de flux de travail que vous pouvez définir. Le premier groupe applique des actions standard lorsqu’un élément de travail est créé, dans un état sélectionné ou est déplacé d’un état à un autre. Ces actions standard définissent la valeur d’un champ ou rendent un champ en lecture seule ou obligatoire. Dans ce groupe, vous pouvez spécifier une ou deux conditions et plusieurs actions.
Les deuxième et troisième groupes prennent en charge les transitions d’état restrictives. Ces deux groupes vous permettent de spécifier une seule condition indiquant l’état vers lequel un élément de travail a été déplacé. Vous pouvez ensuite spécifier une ou plusieurs actions pour restreindre la transition de cet état à d’autres états.
Le tableau suivant indique les deux groupes de règles de flux de travail que vous pouvez définir. Le premier groupe applique des actions standard lorsqu’un élément de travail est créé, dans un état sélectionné ou est déplacé d’un état à un autre. Ces actions standard définissent la valeur d’un champ ou rendent un champ en lecture seule ou obligatoire. Dans ce groupe, vous pouvez spécifier une ou deux conditions et plusieurs actions.
Le deuxième groupe prend en charge la restriction des transitions d’état. Dans ce deuxième groupe, vous pouvez spécifier une seule condition indiquant l’état vers lequel un élément de travail a été déplacé. Vous pouvez ensuite spécifier une ou plusieurs actions pour restreindre la transition de cet état à d’autres états.
Notes
Certaines fonctionnalités nécessitent l’installation de Azure DevOps Server mise à jour 2020.1. Pour plus d’informations, consultez notes de publication Azure DevOps Server 2020 Update 1 RC1, Boards.
Les conditions de flux de travail et les actions que vous pouvez définir sont illustrées dans les images suivantes. Vous pouvez appliquer des actions standard lorsqu’un élément de travail est créé, dans un état sélectionné ou déplacé d’un état à un autre. Ces actions standard définissent la valeur d’un champ ou rendent un champ en lecture seule ou obligatoire. Pour cet ensemble de règles, vous pouvez spécifier une ou deux conditions et plusieurs actions.
Condition
Actions prises en charge
Définir la valeur du champ ou rendre en lecture seule/obligatoire en fonction de l’état
Restreindre une transition basée sur l’état
Masquer le champ ou rendre le champ en lecture seule ou obligatoire en fonction de l’état et de l’appartenance de l’utilisateur ou du groupe
En fonction de et de l’appartenance d’un utilisateur ou d’un groupe, définissez un attribut de champ ou limitez une transition d’état
Notes
Lorsque vous personnalisez un processus hérité, tous les projets qui utilisent ce processus sont automatiquement mis à jour pour refléter les personnalisations. Pour cette raison, nous vous recommandons de créer un processus de test et un projet de test lorsque vous avez un certain nombre de personnalisations à effectuer afin de tester les personnalisations avant de les déployer sur votre organization. Pour plus d’informations, consultez Créer et gérer des processus hérités.
Limites d’état et de règle de flux de travail
Le tableau suivant récapitule les limites l’état du workflow et de la règle pour le processus d’héritage.
Object | Limite d’héritage |
---|---|
Les types d’élément de travail définis pour un processus | 64 |
Les états du workflow définis pour un type d’élément de travail | 32 |
Les règles définies pour un type d’élément de travail | 1 024 |
Lorsque vous définissez les états du workflow et les règles, nous vous recommandons de prendre en compte les conseils suivants afin de réduire les problèmes de performances.
- Réduisez le nombre de règles que vous définissez pour un WIT. Même si vous pouvez créer plusieurs règles pour un WIT, des règles supplémentaires peuvent avoir un impact négatif sur les performances lorsqu’un utilisateur ajoute et modifie des éléments de travail. Lorsque les utilisateurs enregistrent des éléments de travail, le système valide toutes les règles associées aux champs pour son type d’élément de travail. Sous certaines conditions, l’expression de validation de la règle est trop complexe pour l’évaluation de SQL.
- Réduisez le nombre de WIT personnalisés que vous définissez.
Les règles de flux de travail sont appliquées lors de l’ajout ou de la modification d’éléments de travail via l’une des interfaces suivantes :
- Portail web : formulaire d’élément de travail, mises à jour en bloc, mises à jour en mode requête
- Portail web : Tableau Kanban ou Tableau des tâches, déplacer l’élément de travail vers la colonne
- Visual Studio 2017 et versions antérieures, formulaire d’élément de travail
- Format de fichier CSV : importation ou mise à jour en bloc
- Excel : importation ou mise à jour en bloc
- API REST : ajouter ou modifier des éléments de travail
Définir une règle
Avant de définir une règle basée sur les états de flux de travail, veillez à définir d’abord les éléments suivants :
- Le flux de travail indique que vous souhaitez, comme décrit dans Personnaliser un flux de travail
- Si votre règle nécessite la spécification d’un champ personnalisé, ajoutez ce champ au type d’élément de travail, comme décrit dans Ajouter et gérer des champs
- Si votre règle nécessite la spécification d’un groupe de sécurité pour accorder ou restreindre les modifications en fonction de l’appartenance d’un utilisateur ou d’un groupe, définissez ce groupe de sécurité comme décrit dans Ajouter ou supprimer des utilisateurs ou des groupes, gérer les groupes de sécurité.
Pour connaître les principes de base de la définition de règles, consultez Ajouter une règle personnalisée. Vous devez remplir les conditions préalables définies dans cet article.
Définir la valeur du champ ou rendre le champ en lecture seule ou obligatoire
Avec le premier regroupement de règles, vous pouvez spécifier une ou deux conditions et jusqu’à 10 actions par règle.
Exemple de vérification de l’approbation du responsable d’équipe avant le travail actif
Dans cet exemple, les équipes de développement veulent s’assurer qu’aucun récit utilisateur n’est travaillé jusqu’à ce qu’un responsable d’équipe soit approuvé. Les états de flux de travail par défaut sont en cours d’utilisation et un seul champ personnalisé, Approuvé par, et un groupe de sécurité, Team Leads Group, sont ajoutés.
États de workflow par défaut
Conditions requises pour les règles
Pour garantir l’approbation avant le travail actif, les règles suivantes doivent être définies :
- Exiger que le champ Approuvé par soit renseigné lorsque l’état passe de Nouveau à Actif
- Restreindre les utilisateurs qui n’appartiennent pas au groupe de responsables d’équipe à remplir le champ Approuvé par
- Désactivez le champ Approuvé par lorsque l’état passe à Nouveau ou Supprimé
Définitions des règles
Les exigences de règle se traduisent par les quatre définitions de règle suivantes.
Nom de la règle
Condition
Actions
Approuvé Par effacé quand Nouveau
Quand A work item state changes to New
Puis Clear the value of Approved By
Approuvé Par effacé lors de la suppression
Quand A work item state changes to Removed
Puis Clear the value of Approved By
Approuvé par lecture seule
Quand Current user is not member of group Team Leads Group
Puis Make read-only Approved By
Approuvé par obligatoire
Quand A work item state changes from New to Active
Puis Make required Approved By
Restreindre les transitions d'état
Lorsque vous spécifiez la condition, A work item state moved from ...
, vous pouvez spécifier uniquement cette condition. Vous pouvez spécifier jusqu’à 10 actions.
Notes
Cette fonctionnalité nécessite la mise à jour d’Azure DevOps Server 2020.1 ou une version ultérieure.
Exemple de restriction des transitions d’état et de l’état Approuvé
Conformément à la terminologie utilisée par un groupe d’entreprises, les états de flux de travail suivants sont définis pour le récit utilisateur. Les états hérités New, Resolved et Removed sont masqués. Au lieu de cela, les états Proposés, En révision et Couper sont utilisés. En outre, trois états supplémentaires sont définis : Examiner, Concevoir et Approuvé. Ces états doivent suivre la séquence, comme illustré dans l’image suivante.
Sans aucune restriction, les utilisateurs peuvent passer d’un état à un autre état, à la fois vers l’avant et vers l’arrière au sein de la séquence.
Conditions requises pour les règles
Pour prendre en charge un flux de travail plus contrôlé, le groupe d’entreprises a décidé d’établir des règles qui prendraient en charge les transitions d’état avant et inverse suivantes sur le type d’élément de travail User Story.
- Proposé ne peut passer qu’à La recherche et à la coupe
- La recherche ne peut passer qu’à La conception et à la coupe
- La conception peut uniquement passer à Research, Approved et Cut
- Approuvé peut uniquement passer à Design, Active et Cut
- Active peut uniquement passer à En révision
- En révision peut uniquement passer à Actif (travail supplémentaire trouvé), Fermé ou Coupé
- Fermé peut passer à Recherche, Conception, Actif, En révision (Autorise les cas où l’utilisateur a fermé l’élément de travail par erreur)
- Couper peut uniquement passer à Proposé.
Notes
Lorsque vous limitez les transitions d’état, considérez les cas où un utilisateur déplace un état par erreur. Vous souhaitez que les utilisateurs puissent récupérer correctement.
En outre, le groupe d’entreprises souhaite appliquer des règles pour les champs obligatoires :
- Exiger que le champ Approuvé par soit renseigné lorsque l’état passe de Approuvé à Actif
- Autoriser uniquement les utilisateurs qui appartiennent au groupe Approbateurs autorisés à remplir le champ Approuvé par
- Effacer le champ Approuvé par lorsque l’état passe à Couper
- Exiger que les critères d’acceptation soient remplis lorsque l’état passe à Actif
Définitions des règles
Pour implémenter les restrictions ci-dessus, l’administrateur de processus ajoute un champ d’identité approuvé par personnalisé, un groupe de sécurité Approbateurs autorisés et les onze règles suivantes.
Nom de la règle
Condition
Actions
État proposé
Quand A work item state moved from Proposed
Puis Restrict the state transition to Design
And Restrict the state transition to Approved
And Restrict the state transition to Active
And Restrict the state transition to In Review
And Restrict the state transition to Closed
État de la recherche
Quand A work item state moved from Research
Puis Restrict the state transition to Proposed
And Restrict the state transition to Approved
And Restrict the state transition to Active
And Restrict the state transition to In Review
And Restrict the state transition to Closed
État de la conception
Quand A work item state moved from Design
Puis Restrict the state transition to Proposed
And Restrict the state transition to Research
And Restrict the state transition to Active
And Restrict the state transition to In Review
And Restrict the state transition to Closed
État approuvé
Quand A work item state moved from Approved
Puis Restrict the state transition to Proposed
And Restrict the state transition to Research
And Restrict the state transition to Design
And Restrict the state transition to In Review
And Restrict the state transition to Closed
État actif
Quand A work item state moved from Active
Puis Restrict the state transition to Proposed
And Restrict the state transition to Research
And Restrict the state transition to Design
And Restrict the state transition to Approved
And Restrict the state transition to Closed
Dans l’état Révision
Quand A work item state moved from In Review
Puis Restrict the state transition to Proposed
And Restrict the state transition to Research
And Restrict the state transition to Design
And Restrict the state transition to Approved
État fermé
Quand A work item state moved from Closed
Puis Restrict the state transition to Proposed
And Restrict the state transition to Cut
État couper
Quand A work item state moved from Cut
Puis Restrict the state transition to Research
And Restrict the state transition to Design
And Restrict the state transition to Approved
And Restrict the state transition to Active
And Restrict the state transition to In Review
And Restrict the state transition to Closed
Champs d’état approuvé requis
Quand A work item changes from Approved to Active
Puis Make required Acceptance Criteria
And Make required Approved By
Approbateurs autorisés
Quand Current user is not a member of Authorized Approvers
Puis Make read-only Approved By
Effacer le champ Approuvé par
Quand A work item state changes to Cut
Puis Clear the value of Approved By
Vérifier les restrictions de transition d’état
Une fois les règles définies pour le processus et le projet mis à jour avec le processus, actualisez votre navigateur et case activée les opérations via le formulaire d’élément de travail et à partir du navigateur Kanban.
Pour les règles définies dans le tableau précédent, vous devez voir les menus déroulants État suivants. Ouvrez le tableau Kanban et case activée la possibilité de passer d’un état à un autre.
Proposed | Recherche | Conception | Approved |
---|---|---|---|
Actif | En révision | Fermés | Couper |
Restreindre la transition d’état en fonction de l’appartenance d’un utilisateur ou d’un groupe
Lorsque vous spécifiez l’une des deux conditions en fonction de l’appartenance d’un utilisateur ou d’un groupe, Current user is member of group ...
ou Current user is not member of group ...
, vous ne pouvez spécifier qu’une seule condition. En outre, si vous spécifiez l’action Restrict the transition to state...
, vous ne pouvez spécifier qu’une seule action.
Notes
Les éléments de travail sont soumis aux règles qui leur sont appliquées. Les règles conditionnelles basées sur l’appartenance d’un utilisateur ou d’un groupe sont mises en cache pour votre navigateur web. Si vous vous trouvez limité à la mise à jour d’un élément de travail, vous avez peut-être rencontré l’une de ces règles. Si vous pensez que vous avez rencontré un problème qui n’est pas traité ici, consultez Problèmes de mise en cache IndexDB du formulaire d’élément de travail.
Automatiser les transitions d’état des éléments de travail parents
Pour automatiser les transitions d’état des éléments de travail parents en fonction des affectations d’état effectuées à leurs éléments de travail enfants, vous pouvez ajouter un web-hook et utiliser le code et la configuration fournis dans le projet GitHub Automatiser les transitions d’état .
Notes
Le projet GitHub Automatiser les transitions d’état n’est pas une fonctionnalité prise en charge de Azure Boards et n’est donc pas pris en charge par l’équipe produit. Pour les questions, suggestions ou problèmes que vous rencontrez lors de l’utilisation de ces extensions, déclenchez-les dans la page du projet GitHub.
Automatiser la réaffectation en fonction du changement d’état
Le type d’élément de travail bogue du processus Agile avait précédemment une règle qui réaffectait le bogue à la personne qui l’a créé. Cette règle a été supprimée du processus système par défaut. Vous pouvez rétablir la règle ou ajouter une règle similaire à d’autres types d’éléments de travail à l’aide de la condition et de l’action suivantes :
QuandA work item state changes to
Résolu, puisCopy the value from
créé paràAffecté à.
Articles connexes
Notes
Vous pouvez passer en revue les modifications apportées à un processus hérité via le journal d’audit. Pour plus d’informations, consultez Accéder, exporter et filtrer les journaux d’audit.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour