Exemples de scénarios de règles personnalisées

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

Cet article fournit des exemples de définitions de règles personnalisées. Toutes les règles personnalisées sont définies pour un type d’élément de travail. Des exemples sont fournis pour les modèles hérités et locaux de processus XML.

Avant d’ajouter des règles personnalisées, lisez les règles et l’évaluation des règles et ajoutez une règle à un type d’élément de travail (processus d’héritage).

Définir un champ obligatoire dépendant

Vous pouvez spécifier qu’un champ n’est requis que lorsqu’un autre champ contient une valeur spécifique. Dans l’exemple suivant, lorsqu’un client signale un problème, le champ Client Signalé personnalisé est défini sur True et le champ Gravité devient obligatoire. Si le problème n’est pas signalé par un client, une valeur pour le champ Gravité n’est pas requise.

Processus d’héritage

Processus XML local

Vous spécifiez une WHEN instruction de règle pour la définition de champ dans la FIELDS section de la définition de type d’élément de travail.

<FIELDS>
   ...
   <FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">  
       <ALLOWEDVALUES>  
           <LISTITEM value="Blocking" />  
           <LISTITEM value="Major" />  
           <LISTITEM value="Minor" />  
       </ALLOWEDVALUES>  
       <WHEN field="MyCorp.CustomerReported" value="true">  
           <REQUIRED />  
       </WHEN>  
   </FIELD> 
   ...
</FIELDS>     

Effacer la valeur d’un champ dépendant

L’exemple suivant illustre la définition d’une règle personnalisée pour effacer la valeur des points d’histoire lorsqu’une modification est apportée à la date de début.

Processus d’héritage

Processus XML local

Vous spécifiez une WHENCHANGED instruction de règle pour la définition de champ dans la FIELDS section de la définition de type d’élément de travail.

<FIELDS>
 ...
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
       <HELPTEXT>The size of work estimated for implementing this user story</HELPTEXT>
       <WHENCHANGED field="Microsoft.VSTS.Scheduling.StartDate">  
           <EMPTY />  
       </WHENCHANGED>
   </FIELD>
   ...
</FIELDS>     

Définir une valeur de champ dépendante

Les exemples suivants illustrent comment mapper les valeurs du champ Taille en fonction de la valeur sélectionnée pour le champ personnalisé, champ Taille du tee-shirt.

Processus d’héritage

La liste de choix taille du tee-shirt se compose de quatre valeurs Small, Medium, Large et X-Large. Quatre règles personnalisées sont définies pour affecter le champ Taille lorsque le champ Taille du tee-shirt est remplacé par une valeur spécifique. Pour simplifier l’utilisation, la valeur par défaut de la taille du tee-shirt est petite.

Boîte de dialogue Modifier le champ Taille du tee-shirt

Règle personnalisée

Quatre règles personnalisées

Processus XML local

Vous spécifiez la valeur du champ Taille dans la section de la FIELDS définition de type d’élément de travail. Vous utilisez une série d’instructions de WHEN règle pour effectuer le mappage, en définissant la valeur du champ Taille à l’aide de la COPY value="value" règle.

<FIELDS>
   ...
   <FIELD name="Tee-Shirt Size" refname="Fabrikam.TShirt.Size" type="String">
        <HELPTEXT>Estimate of overall size for work to be done; Small (2), Medium (6), Large (18), X-Large (30).</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Large" />
          <LISTITEM value="Medium" />
          <LISTITEM value="Small" />
          <LISTITEM value="X-Large" />
        </ALLOWEDVALUES>
   </FIELD> 
   <FIELD name="Size" refname="Fabrikam.Size" type="Integer">
        <HELPTEXT>Integer estimate of overall size for work to be done; Automatically fill in based on Tee-Shirt Size. Allow any value.</HELPTEXT>
        <WHEN field="Fabrikam.TShirt.Size" value="Small">
          <COPY value="2" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Medium">
          <COPY value="6" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Large">
          <COPY value="18" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="X-Large">
          <COPY value="30" />
        </WHEN>
   </FIELD>
   ...
 </FIELDS> 

Exiger une valeur de champ lors des modifications d’état

L’exemple suivant montre comment vous pouvez exiger la spécification du champ Travail restant lorsque l’état du flux de travail de tâche passe à Actif.

Processus d’héritage

Processus XML local

Lorsque la valeur du champ État d’un élément de travail est définie sur Active et que l’élément de travail est enregistré, les valeurs des champs Activé par et Affecté à sont automatiquement définies sur le nom de l’utilisateur actuel. Cet utilisateur doit être membre du groupe Utilisateurs valides Team Foundation Server. La valeur du champ Date activée est également définie automatiquement. L’exemple suivant montre les éléments qui appliquent cette règle :

<WORKFLOW>
. . .  
    <STATE value="Active">
        <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <REQUIRED />
            </FIELD>
        </FIELDS>
    </STATE>
. . .  
</WORKFLOW>

Effacer la valeur d’un champ lors de la fermeture de l’état

Pour automatiser l’effacement du champ Travail restant lors de la fermeture d’une tâche, définissez une règle personnalisée comme indiqué.

Processus d’héritage

Processus XML local

<WORKFLOW>
. . .  
      <STATE value="Closed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <EMPTY />
            </FIELD>
          </FIELDS>
      </STATE>
. . .  
</WORKFLOW>

Restreindre la création d’éléments de travail par un groupe

Une règle personnalisée qui limite la transition vers la catégorie d’état proposé d’un type d’élément de travail interdit efficacement la création d’éléments de travail de ce type. En appliquant la règle à un groupe spécifique, vous empêchez efficacement ce groupe de créer des éléments de travail de ce type.

Processus d’héritage

La règle personnalisée suivante empêche une équipe de projet de créer des éléments de travail en tant que catégorie d’état proposée est mappée à l’état Nouveau flux de travail.

Processus XML local

La règle personnalisée suivante limite l’équipe de révision Fabrikam (pour l’attribut) à la création d’éléments de travail en désallonçant la transition vers l’état Nouveau flux de travail.

<WORKFLOW>
... 
<TRANSITION from=" " to="New"  
   for="[Project]\Developers" 
   not="[Project]\Fabrikam Review Team"  
   . . .  
</TRANSITION> 
...  
</WORKFLOW>

Restreindre la modification des éléments de travail par un groupe

Pour un processus d’héritage, vous pouvez empêcher les utilisateurs de modifier un élément de travail en définissant l’autorisation refuser pour un groupe sur un chemin d’accès à la zone. Pour un processus XML local, vous pouvez placer des restrictions sur chaque état de flux de travail d’un groupe qui les empêche d’enregistrer l’élément de travail dans n’importe quel état.

Processus d’héritage

Il n’est pas possible de définir une règle personnalisée qui limite la modification des éléments de travail d’un type spécifique. Vous ne pouvez spécifier que la restriction par état. Si l’utilisateur ne modifie pas l’état, il peut modifier d’autres champs, sauf si tous les champs sont effectués en lecture seule pour le groupe.

Au lieu de cela, si vous souhaitez restreindre un groupe d’utilisateurs à modifier la sélection d’éléments de travail de n’importe quel type, vous pouvez affecter ces éléments de travail à un chemin d’accès de zone. Définissez un groupe de sécurité, puis définissez des restrictions pour modifier les éléments de travail pour ce chemin d’accès de zone pour ce groupe, comme illustré dans l’image suivante. Pour plus d’informations, consultez Définir les autorisations et l’accès pour le suivi du travail, Créer des nœuds enfants et modifier des éléments de travail sous un chemin d’accès de zone

Processus XML local

La règle personnalisée suivante limite l’équipe de révision Fabrikam (pour l’attribut) à modifier les récits utilisateur en supprimant tous les états de flux de travail définis pour le type d’élément de travail de l’article utilisateur. Étant donné qu’aucun état de flux de travail n’est valide pour l’équipe spécifique, les membres de cette équipe ne peuvent pas enregistrer l’élément de travail avec des modifications.

<WORKFLOW>
... 
 <STATE value="New">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Active">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Resolved">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Closed">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
...  
</WORKFLOW>

Restreindre les transitions d’état

Pour les processus hérités, les transitions d’état any-to-any sont automatiquement définies. Cela permet aux utilisateurs d’avancer l’état du flux de travail de nouveau à terminé, mais également de reculer en cas de besoin. Lorsque vous définissez des règles personnalisées pour restreindre une transition, gardez à l’esprit que si un utilisateur fait une erreur lors de la mise à jour du flux de travail, il se peut qu’il ne soit pas en mesure de le corriger. Par exemple, ils peuvent mettre à jour l’état en déplaçant un élément de travail carte vers une étape ultérieure du tableau Kanban, mais pas le déplacer vers l’arrière.

Conseil

Envisagez de restreindre une transition d’état pour certains utilisateurs, mais pas tous. De cette façon, si un utilisateur fait une erreur, il peut demander à un autre membre de l’équipe de réinitialiser la valeur d’état pour contourner la restriction.

Avant de définir des règles de transition d’état, passez en revue les règles et l’évaluation des règles, les règles générées automatiquement et la façon dont les états de flux de travail et les catégories d’état sont utilisés dans les backlogs et les tableaux.

Restreindre la modification des éléments de travail fermés

Selon vos processus métier, vous pouvez empêcher les utilisateurs de continuer à modifier ou mettre à jour des éléments de travail qui ont été fermés ou terminés. Vous pouvez ajouter des règles aux types d’éléments de travail pour empêcher les utilisateurs de rouvrir les éléments de travail fermés.

Processus d’héritage

Pour le processus hérité, vous pouvez ajouter une règle qui limite la transition d’état. Par exemple, la règle suivante limite la transition de la fermeture aux deux autres États, Nouveau et Actif.

Remarque

La A work item state moved from ... condition est disponible pour Azure DevOps Server 2020 et versions ultérieures.

Remarque

Selon l’action de règle que vous spécifiez, le bouton Enregistrer du formulaire d’élément de travail peut être désactivé ou un message d’erreur s’affiche lorsqu’un utilisateur restreint tente de modifier l’élément de travail.

Processus XML local

Pour les déploiements locaux, vous pouvez ajouter des règles à un type d’élément de travail pour empêcher la nouvelle ouverture après la fermeture d’un élément de travail. Par exemple, les règles de transition de flux de travail suivantes permettent aux testeurs de rouvrir un élément de travail, mais pas aux membres du groupe Développeurs.

<WORKFLOW>
. . .  
<TRANSITION from="Closed" to="New"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
. . .  
</WORKFLOW>

Masquer ou restreindre la modification d’un champ en fonction d’un utilisateur ou d’un groupe

Lorsque vous sélectionnez ou Current user is a member of group...Current user is not a member of group..., vous pouvez masquer un champ, créer un champ en lecture seule ou rendre un champ requis.

Par exemple, la condition suivante indique que le champ Justification est masqué pour les membres qui n’appartiennent pas au groupe Fabrikam Fibre\Voice.

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.

Restreindre la modification de certains champs en fonction d’un utilisateur ou d’un groupe

Vous pouvez personnaliser les types d’éléments de travail pour restreindre les personnes pouvant modifier un champ spécifique pour un type d’élément de travail.

Processus d’héritage

À l’aide de l’une des deux conditions suivantes, vous pouvez définir des champs sélectionnés requis pour un utilisateur d’un groupe de sécurité ou qui ne sont pas membres d’un groupe de sécurité.

• current user is a member of a group...
• current user is not a member of a group...

Conseil

Pour éviter les problèmes d’évaluation des règles qui peuvent survenir, spécifiez des groupes de sécurité Azure DevOps et non des groupes de sécurité Microsoft Entra ou Active Directory. Pour en savoir plus, consultez les règles par défaut et le moteur de règles.

Par exemple, vous pouvez définir le titre ou les champs État en lecture seule pour sélectionner des utilisateurs ou des groupes.

Par exemple, le champ Priorité , pour le type d’élément de travail User Story, devient en lecture seule pour les membres du groupe Fabrikam Fibre\Voice. Lorsqu’un utilisateur de ce groupe ouvre un récit utilisateur, il ne peut pas modifier la valeur sur le champ Priorité.

Processus XML local

Pour le modèle de processus XML local, vous pouvez personnaliser les types d’éléments de travail pour prendre en charge ces demandes de restriction :

• Restreindre les personnes pouvant créer ou modifier un élément de travail
• Restreindre les personnes pouvant créer des types d’éléments de travail spécifiques, tels que des épopées ou des fonctionnalités

Par exemple, vous pouvez restreindre la modification des éléments de travail en ajoutant une règle au type d’élément de travail, généralement dans la section WORKFLOW .

Vous limitez l’accès aux objets de suivi de travail de l’une des deux manières suivantes :

• Définissez une règle de champ de condition, une règle de champ basé sur une condition ou une combinaison des deux qui s’appliquent à un groupe. Vous pouvez restreindre les modifications apportées à un champ en spécifiant une règle éligible et en l’appliquant à un groupe spécifique. Les règles conditionnelles peuvent inclure les éléments CANNOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY et REQUIRED .
• En ajoutant des WIT au groupe Catégories masquées, vous pouvez empêcher la majorité des contributeur de projet de les créer. Vous pouvez créer un lien hypertexte vers un modèle qui ouvre le formulaire d’élément de travail et partager ce lien avec les membres de l’équipe que vous souhaitez créer.

Articles connexes

• Appliquer des règles aux états de workflow (processus d’héritage)
• Règles et évaluation des règles