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é vos états de flux de travail pour un type d’élément de travail, vous pouvez définir une ou plusieurs règles appliquées en fonction du changement d’état du flux de travail. L’ajout de règles aux états de flux de travail prend en charge les scénarios suivants :

• Prendre en charge un processus d’approbation
• Empêcher les utilisateurs non autorisés de définir un état non valide
• Définir un champ requis ou en lecture seule ou une autre valeur en fonction des modifications d’état
• Restreindre la transition d’un état à un autre
• Restreindre ou autoriser les transitions d’état vers des utilisateurs ou des 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 parent

Passez en revue cet article pour comprendre comment définir des règles qui s’appliquent lorsque vous modifiez un état de 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 créer 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 vers des utilisateurs ou des groupes spécifiques
• Automatiser les transitions d’état des éléments de travail parents

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 déplacé d’un état à un autre. Ces actions standard définissent la valeur d’un champ ou rend 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 la restriction des transitions d’état. 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.

---

Condition

Actions prises en charge

---

Définir la valeur du champ ou rendre en lecture seule/obligatoire en fonction de l’état

---

En fonction de l’appartenance de l’utilisateur ou du groupe, définissez un attribut de champ ou limitez une transition d’état

---

Remarque

Lorsque vous personnalisez un processus hérité, tous les projets qui utilisent ce processus reflètent automatiquement les personnalisations. Pour garantir une transition fluide, nous vous recommandons de créer un processus de test et un projet, ce qui vous permet de tester vos personnalisations avant de les implémenter à l’échelle de l’organisation. Pour plus d’informations, consultez Créer et gérer des processus hérités.

Limites d’état et de règle du 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 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’abord à définir 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 à l’utilisateur ou au groupe, définissez ce groupe de sécurité comme décrit dans Ajouter ou supprimer des utilisateurs ou des groupes, gérer des 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 respecter 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 des prospects d’équipe avant le travail actif

Dans cet exemple, les équipes de développement souhaitent s’assurer qu’aucune histoire d’utilisateur n’est travaillée jusqu’à ce qu’elle soit approuvée par un responsable d’équipe. Les états de flux de travail par défaut sont en cours d’utilisation et seuls un seul champ personnalisé, approuvé par et groupe de sécurité, groupe de prospects d’équipe, sont ajoutés.

États de flux de travail 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 prospects d’équipe pour renseigner le champ Approuvé par
• Effacer 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é lorsque nouveau

Quand A work item state changes to New

Alors Clear the value of Approved By

Approuvé par effacé lors de la suppression

Quand A work item state changes to Removed

Alors Clear the value of Approved By

Approuvé par lecture seule

Quand Current user is not member of group Team Leads Group

Alors Make read-only Approved By

Approuvé par obligatoire

Quand A work item state changes from New to Active

Alors Make required Approved By

---

Restreindre les transitions d’état

Lorsque vous spécifiez la condition, A work item state moved from ...vous ne pouvez spécifier que cette condition. Vous pouvez spécifier jusqu’à 10 actions.

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 l’article 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 Approuver. 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 dans 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’instituter des règles qui prenaient en charge les transitions d’état vers l’avant et inverse suivantes sur le type d’élément de travail User Story.

• Proposé ne peut passer qu’à la recherche et à couper
• La recherche ne peut passer qu’à La conception et à la coupe
• La conception ne peut passer qu’à la recherche, approuvée et couper
• L’approbation ne peut passer qu’à Conception, Actif et Couper
• Actif ne peut passer qu’à Révision
• En révision , vous pouvez uniquement passer à Actif (Travail supplémentaire trouvé), Fermé ou Coupé
• Fermé peut passer à recherche, conception, actif, en révision (permet aux utilisateurs de fermer l’élément de travail en cas d’erreur)
• Couper ne peut passer qu’à Proposé.

Remarque

Lorsque vous limitez les transitions d’état, tenez compte des cas où un utilisateur déplace un état en 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 appartenant au groupe Approbateurs autorisés à renseigner le champ Approuvé par
• Effacer le champ Approuvé par lorsque l’état passe à Couper
• Exiger que les critères d’acceptation soient renseignés lorsque l’état passe à Actif

Définitions des règles

Pour implémenter les restrictions ci-dessus, l’administrateur de processus ajoute un champ approuvé par identité 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

Alors 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 recherche

Quand A work item state moved from Research

Alors 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 conception

Quand A work item state moved from Design

Alors 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

Alors 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

Alors 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 De révision

Quand A work item state moved from In Review

Alors 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

Alors Restrict the state transition to Proposed
And Restrict the state transition to Cut

État couper

Quand A work item state moved from Cut

Alors 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 obligatoires de l’état approuvé

Quand A work item changes from Approved to Active

Alors Make required Acceptance Criteria
And Make required Approved By

Approbateurs autorisés

Quand Current user is not a member of Authorized Approvers

Alors Make read-only Approved By

Effacer approuvé par champ

Quand A work item state changes to Cut

Alors 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 vérifiez les opérations via le formulaire d’élément de travail et à partir du navigateur.

Pour les règles définies dans le tableau précédent, vous devez voir les menus déroulants d’état suivants. Ouvrez la carte et vérifiez la possibilité de passer d’un état à un autre.

Proposé	Recherche	Conception	Approuvé(e)
Actif	En revue	Fermés	Couper

Restreindre la transition d’état en fonction de l’appartenance de l’utilisateur ou du groupe

Lorsque vous spécifiez l’une des deux conditions en fonction de l’appartenance de l’utilisateur ou du 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.

Remarque

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 apportées à leurs éléments de travail enfants, vous pouvez ajouter un hook web et utiliser le code et la configuration fournis dans le projet GitHub Automatiser les transitions d’état.

Remarque

Le projet GitHub Automate State Transitions n’est pas une fonctionnalité prise en charge d’Azure Boards et n’est donc pas pris en charge par l’équipe produit. Pour des questions, des suggestions ou des 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 :

Lors A work item state changes to de la résolution, créez ensuite Copy the value from par l’affectation.

Articles connexes

Remarque

Passez en revue les modifications apportées à un processus hérité par le biais du journal d’audit. Pour plus d’informations, consultez Access, exporter et filtrer les journaux d’audit.

• Personnaliser un flux de travail
• Ajouter une règle personnalisée
• Mise en cache des formulaires d’élément de travail