Règles et évaluation des règles

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

Les règles servent à définir ou restreindre les attributions de valeurs à un champ d’élément de travail. Il existe deux principaux types de règles : les règles générées automatiquement et les règles personnalisées définies pour un processus ou un projet. Les règles générées automatiquement réduisent la nécessité d’ajouter des règles personnalisées pour les zones devant fonctionner de manière standard.

Vous définissez des règles personnalisées pour prendre en charge vos cas d’usage professionnels. Selon le type de données d’un champ, vous pouvez définir différentes restrictions sur les données qui peuvent être entrées dans ce champ. Vous pouvez spécifier des valeurs pour une liste de choix (menu déroulant), définir des valeurs par défaut, effacer des entrées ou limiter les modifications. Les règles conditionnelles vous permettent d’appliquer des règles à un champ en fonction des dépendances entre les différentes valeurs des champs. Vous pouvez également limiter les personnes autorisées à modifier un champ ou limiter la portée d'une règle pour qu'elle s'applique uniquement à un groupe.

Lisez cet article pour comprendre les éléments suivants :

• Comment le système applique les règles générées automatiquement
• Restrictions placées sur la définition de règles personnalisées sur les champs système
• Les différents types de règles personnalisées que vous pouvez appliquer
• Évaluation des règles
• Différence entre les règles définies pour un processus d’héritage et un processus XML local
• Pourquoi réduire le nombre de règles personnalisées que vous définissez

Avant de définir des règles personnalisées, lisez Configurer et personnaliser Azure Boards pour mieux comprendre comment personnaliser Azure Boards pour répondre aux besoins de votre entreprise.

Conseil

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ègles générées automatiquement

Les règles générées automatiquement réduisent la nécessité d’ajouter des règles personnalisées pour les zones devant fonctionner de manière standard.

Règles de transition d’état

Les processus hérités génèrent l’ensemble entier des règles de transition d’état à n’importe quel de manière dynamique pour chaque type d’élément de travail personnalisé et l’état personnalisé ajoutés à un flux de travail. Une transition de n’importe quel état à n’importe quel état est valide.

Pour les processus XML locaux, vous devez spécifier les transitions valides dans la section de la WORKFLOW définition de type d’élément de travail.

Transitions d’état et règles de champ By/Date

Les champs By/Date correspondent aux champs By/Date créés, Activés par/Date, Résolus par/Date et Fermés par/Date.

Pour les processus hérités, ces champs sont automatiquement définis ou effacés lorsque vous transférez un élément de travail d’un état à un autre. Les champs Modifiés par/date ne sont pas inclus, car ils sont mis à jour avec chaque enregistrement d’élément de travail et ne sont pas liés aux transitions d’état.

Les règles et comportements par défaut qui régissent ces champs sont les suivants :

1. L’état fermé est toujours contenu dans la catégorie d’état Terminé .
2. La catégorie d’état Terminé n’est pas configurable et est associée à un seul état.
3. Cet état fermé est toujours fermé pour les processus Agile et CMMI, et toujours Terminé pour les processus Scrum et De base.
4. La génération automatique de ces règles est affectée par les paramètres régionaux, car la condition de règle contient le nom d’état, qui est localisé. Le système génère différentes règles pour différents paramètres régionaux.
5. Les règles générées automatiquement pour ces champs sont spécifiées uniquement pour les types d’éléments de travail qui incluent ces champs. Il est possible qu’un type d’élément de travail n’inclue pas un ou plusieurs de ces champs.
6. Ces règles sont nécessaires lorsqu’un type d’élément de travail a des états personnalisés ou que le type d’élément de travail est un type d’élément de travail personnalisé.
7. Ces règles s’appliquent uniquement aux processus hérités ; elles ne sont jamais générées pour les processus XML hébergés ou XML locaux.

Les états de flux de travail sont associés aux catégories d’état pour prendre en charge le flux de travail sur les tableaux. Pour plus d’informations, consultez Utilisation des états et des catégories d’état des workflows dans les backlogs et les tableaux.

Règles de champ Date de modification de l’état

Ces règles sont techniquement beaucoup plus simples que les règles Close By/Closed Date, car elles ne dépendent pas d’un état particulier. Pour tout type d’élément de travail, les mêmes règles fonctionnent toujours. Ils doivent être générés automatiquement, car certains types d’éléments de travail OOB ne contiennent pas le champ Date de modification d’état. Par conséquent, lorsque l’utilisateur ajoute ce champ à un type d’élément de travail personnalisé, ces règles doivent également être générées automatiquement. Les mêmes principes pour les règles de date fermée/fermée s’appliquent également ici.

Règles personnalisées

Toutes les règles personnalisées sont facultatives. Pour un processus hérité, vous spécifiez une règle qui se compose d’une condition plus d’action. Pour un processus XML local, vous spécifiez des règles pour un champ ou dans le flux de travail.

Il n’existe pas de mappage un-à-un entre les deux processus. Dans certains cas, la règle d’élément XML est définie dans la boîte de dialogue Modifier le champ pour le processus hérité et non en tant que règle. D’autres éléments XML, tels que FROZEN, , MATCHNOTSAMEAS, ne sont pas pris en charge dans le processus hérité.

Notez ce qui suit :

• Les règles sont toujours appliquées, non seulement lorsque vous interagissez avec le formulaire, mais aussi lors de l’interfaçage via d’autres outils. Par exemple, la définition d’un champ en lecture seule applique non seulement la règle sur le formulaire d’élément de travail, mais également via l’API et le complément De serveur Azure DevOps Excel.
• Les entrées de processus héritées spécifient des conditions et des actions pour effectuer une règle complète. Les éléments XML ne font pas ces distinctions.
• Les règles de champ ne prennent pas en charge l’affectation de valeurs qui sont la somme de deux autres champs ou effectuant d’autres calculs mathématiques. Toutefois, vous pouvez trouver une solution qui répond à vos besoins via l’extension TFS Aggregator (service web) Marketplace. Voir également Cumul du travail et d’autres champs.
• Vous trouverez peut-être des solutions supplémentaires pour appliquer des règles personnalisées à des champs à l’aide d’extensions de la Place de marché, telles que l’extension de bibliothèque de contrôle de formulaire d’élément de travail.

Composition des règles

Processus d’héritage

Pour un processus hérité, chaque règle se compose de deux parties : conditions et actions. Les conditions définissent les circonstances qui doivent être remplies pour que la règle soit appliquée. Les actions définissent les opérations à effectuer. Pour la plupart des règles, vous pouvez spécifier un maximum de deux conditions et 10 actions par règle. Toutes les règles personnalisées nécessitent que toutes les conditions soient remplies afin d’être exécutées.

Par exemple, vous pouvez rendre un champ requis en fonction de la valeur affectée à l’état et à un autre champ. Par exemple :

   (Condition) When a work item State isActif
   (Condition) And when the value ofZone = valeurAffaire
   (Action) Then make requiredPoints d’histoire

Notes

Actuellement, une seule condition est prise en charge pour les règles de transition d’état. Si vous appliquez des règles basées sur l’état, consultez Appliquer des règles aux états de flux de travail.

Le tableau suivant résume les actions disponibles avec les conditions sélectionnées.

Condition

Actions prises en charge

Définir la valeur du champ ou rendre obligatoire ou en lecture seule

Restreindre une transition basée sur l’état

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

Processus XML local

Le processus XML local définit des règles à l’aide d’éléments XML. Tous ces éléments de règle peuvent être définis dans la FIELD définition d’une définition de type d’élément de travail. Et, à l’exception de l’élément HELPTEXT , vous pouvez spécifier ces règles à prendre en charge pendant une transition de flux de travail ou en tant qu’éléments enfants dans un FIELD élément (workflow global).

Notes

L’élément VALIDUSER n’est pas pris en charge pour TFS 2018 et versions ultérieures.

Où appliquer une règle de champ

Lorsque vous souhaitez qu’une règle s’applique à un champ tout au long de la durée de vie de l’élément de travail, spécifiez-la dans la FIELD section. Par exemple, un champ requis pour un bogue qui est nouveau et actif reste requis jusqu’à ce que le bogue soit fermé. Sinon, si vous souhaitez qu’elle soit appliquée en fonction d’une modification de l’état, de la raison ou de la transition, spécifiez-la dans la WORKFLOW section.

Les champs State (System.State) et Reason (System.Reason) sont définis dans la WORKFLOW section. Vous pouvez spécifier la plupart des règles de champ à appliquer à un champ lors d’un changement d’état, de sélection d’une raison ou d’une transition spécifique. Pour plus d’informations, consultez Modifier le flux de travail pour un type d’élément de travail.

Sinon, spécifiez une règle à évaluer uniquement pendant une modification de l’état. Ces règles sont définies dans la WORKFLOW section sous les éléments ou REASONTRANSITION les STATEéléments. Toutes les règles, à l’exception HELPTEXTde celles-ci, peuvent être appliquées dans un FIELD élément (Workflow).

Les règles de champ sont additifs. Autrement dit, vous pouvez spécifier quatre ensembles de règles pour le même champ qui sera évalué par le moteur de règles.

• Les règles spécifiques au type d’élément de travail s’appliquent indépendamment de l’emplacement d’un élément de travail dans son modèle d’état. Par exemple, une <REQUIRED \> règle effectue la vérification suivante :

  "MyField Value" != NULL

• Les règles spécifiques à l’état sont limitées à une instance d’élément de travail lorsqu’elles se trouvent dans un état donné. Une règle spécifique à l’état est appliquée lorsque la condition suivante a la valeur true :

  State field value == "MyState" && "MyField Value" != NULL

• Les règles spécifiques à la transition que vous spécifiez pour une transition spécifique sont limitées à un élément de travail qui subit une certaine transition. Ces règles sont appliquées lorsque les conditions suivantes sont remplies :

  State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL

• Les règles spécifiques à la raison que vous spécifiez pour une raison spécifique sont limitées à une raison particulière pour une transition particulière. Ils sont traités lorsque les conditions suivantes sont remplies :

  Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

L’exemple suivant limite la modification du champ de gravité du client lorsque l’élément de travail est dans l’état Actif.

XML

<STATE name="Active">
      <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
      </FIELDS>
</STATE>

Que se passe-t-il si trop de règles sont définies

Une expression SQL unique est définie par projet pour valider les éléments de travail chaque fois qu’ils sont créés ou mis à jour. Cette expression augmente avec le nombre de règles que vous spécifiez pour tous les types d’éléments de travail définis pour le projet. Chaque qualificateur comportemental spécifié pour un champ entraîne une augmentation du nombre de sous-expressions. Les règles imbriquées, les règles qui s’appliquent uniquement à une transition ou conditionnées sur la valeur d’un autre champ, entraînent l’ajout de conditions supplémentaires à une IF instruction. Une fois que l’expression atteint une certaine taille ou complexité, SQL ne peut plus l’évaluer et génère une erreur. La suppression de certains WIT ou l’élimination de certaines règles peut résoudre l’erreur.

Vous pouvez spécifier des valeurs pour une liste de choix (menu déroulant), définir des valeurs par défaut, effacer des entrées ou limiter les modifications. Les règles conditionnelles vous permettent d’appliquer des règles à un champ en fonction des dépendances entre les différentes valeurs des champs. Vous pouvez également limiter les personnes autorisées à modifier un champ ou limiter la portée d'une règle pour qu'elle s'applique uniquement à un groupe.

Les règles d’élément de travail n’existent pas en tant que collection unique. Les règles sont réellement générées et fusionnées dynamiquement à partir de différentes sources de données. La logique de fusion est simple, consolidez des règles identiques, mais ne supprimez pas les règles en conflit.

Règles de contournement

En général, tous les éléments de travail sont validés par le moteur de règles lorsque les utilisateurs modifient l’élément de travail. Toutefois, pour prendre en charge certains scénarios, les utilisateurs affectés aux règles de contournement sur les mises à jour des éléments de travail peuvent enregistrer les éléments de travail sans que les règles soient évaluées.

Les règles peuvent être contournées de l’une des deux manières. La première consiste à utiliser les éléments de travail - mettre à jour l’API REST et définir le bypassRules paramètre truesur . La seconde consiste à passer par le modèle objet client, en initialisant en mode contournement (initialiser WorkItemStore avec WorkItemStoreFlags.BypassRules).

Champs système et règles personnalisées

Les champs système ont System.Noms de référence de nom , par exemple System.Title et System.State.

Les champs système suivants doivent avoir une valeur : ID de zone, Date modifiée, Date de création, Création par, État et Raison.

Le moteur de règle limite les conditions ou les actions aux champs système, à l’exception des suivantes :

• Vous pouvez définir les champs État et Motif en lecture seule.
• Vous pouvez appliquer la plupart des règles au titre, affecté à, description et modifié par les champs.

Si vous ne voyez pas de champ répertorié dans le menu déroulant de l’interface utilisateur de règle pour le processus d’héritage, c’est pourquoi. Par exemple, si vous essayez de rendre le chemin d’accès à la zone (System.AreaPath) en lecture seule en fonction d’une condition, le champ Chemin d’accès à la zone n’est pas disponible pour la sélection. Même si vous êtes en mesure de spécifier un champ système, le moteur de règle peut vous empêcher d’enregistrer la règle.

Règles de copie et par défaut

Les règles de copie et par défaut modifient les valeurs des champs d’élément de travail. Ils définissent le comportement et les contraintes au moment de l’exécution, telles que la spécification des valeurs par défaut, l’effacement des champs, la définition de champs, etc.

Vous pouvez restreindre l’application de ces règles en fonction de l’appartenance au groupe de l’utilisateur actuel, comme décrit dans les restrictions des règles d’appartenance aux utilisateurs ou aux groupes.

Processus d’héritage

La plupart de ces actions de règle peuvent être appliquées avec la sélection de n’importe quelle condition.

Action de processus héritée

Description

Copy the value from...

Spécifie un autre champ qui contient une valeur à copier dans le champ actif.

Clear the value of...

Efface le champ de n’importe quelle valeur qu’il contient.

Use the current time to set the value of ...

Définit l’heure d’un champ en fonction du paramètre d’heure de l’utilisateur actuel.

Processus XML local

Ces règles prennent en charge la définition des valeurs par défaut, la copie de valeurs d’un champ vers un autre ou l’application d’une valeur de champ pour correspondre à un modèle prescrit. Pour obtenir la structure de syntaxe et les exemples, consultez Définir une valeur par défaut ou copier une valeur dans un champ.

Élément XML

Utilisation

COPY

Copie une valeur spécifiée dans un champ lorsqu’un utilisateur crée ou modifie un élément de travail.

XML

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD> 

DEFAULT

Spécifie une valeur pour un champ vide lorsqu’un utilisateur crée ou modifie un élément de travail. Si un champ a déjà une valeur, la DEFAULT règle est ignorée. Les règles par défaut s’exécutent uniquement si la Is valeur du champ est actuellement vide. Les valeurs prises en charge incluent l’heure actuelle (from = "clock"), l’utilisateur actuel (from = "currentuser"), une valeur littérale (from = "value" value = "literal") ou la valeur d’un autre champ (from = field field = "referenceNameField").

XML

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD 

SERVERDEFAULT

Spécifie l’horloge du serveur ou l’utilisateur actuel pour définir une valeur de champ.

XML

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>  

Règles de contrainte

Les règles de contrainte limitent la modification de la valeur d’un champ. Ils définissent les états valides pour un élément de travail. Chaque contrainte fonctionne sur un seul champ. Les contraintes sont évaluées sur le serveur sur l’enregistrement d’élément de travail, et si une contrainte est enfreinte, l’opération d’enregistrement est rejetée.

Vous pouvez restreindre l’application de ces règles en fonction de l’appartenance au groupe de l’utilisateur actuel, comme décrit dans les restrictions des règles d’appartenance aux utilisateurs ou aux groupes.

Processus d’héritage

La plupart de ces actions de règle peuvent être appliquées avec la sélection de n’importe quelle condition.

Action de processus héritée

Description

Hide the field...
Disponible uniquement lorsqu’une condition d’appartenance au groupe est sélectionnée.

Spécifie de ne pas afficher le champ sur le formulaire d’élément de travail, en supprimant essentiellement la possibilité pour l’utilisateur actuel de modifier la valeur du champ.

Make read-only

Empêche la modification d’un champ. Vous souhaiterez peut-être appliquer cette règle dans certaines conditions. Par exemple, une fois qu’un élément de travail est fermé, vous souhaitez créer un champ en lecture seule pour conserver les données à des fins de création de rapports.
Pour spécifier la valeur par défaut du champ est en lecture seule, spécifiez dans la boîte de dialogue Modifier le champ, onglet Options .

Make required

Nécessite qu’un utilisateur spécifie une valeur pour le champ. Les utilisateurs ne peuvent pas enregistrer un élément de travail tant qu’ils n’ont pas affecté des valeurs à tous les champs obligatoires.
Pour spécifier la valeur par défaut du champ, spécifiez dans la boîte de dialogue Modifier le champ, onglet Options .

Processus XML local

Élément XML

Utilisation

ALLOWEDVALUES

Définit une liste de valeurs autorisées pour le champ. Les valeurs autorisées sont des valeurs disponibles pour la sélection dans une liste de champs sur les formulaires d’élément de travail et dans le générateur de requêtes. Vous devez sélectionner l’une de ces valeurs.

CANNOTLOSEVALUE

Empêche les utilisateurs d’effacer un champ d’une valeur une fois qu’une valeur a été spécifiée. Cet élément conserve la valeur de champ actuelle et ne peut pas être effacé ou rendu vide.

XML

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD> 

FROZEN

Empêche les utilisateurs de modifier la valeur d’un champ une fois qu’il contient une valeur. Dès qu’un utilisateur enregistre l’élément de travail avec une valeur dans ce champ, la valeur ne peut plus être modifiée. Un champ figé ne peut pas être remplacé par une valeur non vide après la validation des modifications. Toutefois, vous pouvez effacer manuellement le champ, enregistrer l’élément de travail, puis spécifier une autre valeur.

XML

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD> 

EMPTY

Efface le champ de n’importe quelle valeur qu’il contient, puis rend le champ en lecture seule lorsqu’un utilisateur enregistre l’élément de travail. Vous ne devez pas utiliser EMPTY avec READONLY.
EMPTY est principalement utilisé pendant la transition d’état pour effacer les champs qui s’appliquent à l’état auquel l’élément effectue la transition.

XML

<FIELD refname="MyCorp.SubStatus" />  
   <WHEN field="MyCorp.Status" value="Approve" >  
     <EMPTY />
   </WHEN>  
</FIELD>  

MATCH

Force les entrées effectuées dans un champ String à se conformer à un modèle de caractères ou de nombres spécifié. Si vous définissez plusieurs MATCH éléments, la valeur est considérée comme valide si elle correspond à l’un des modèles que vous spécifiez. Si au moins un élément réussit, le champ a une valeur valide.

XML

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

Empêche l’attribution d’un champ à la même valeur que celle qui a été affectée à un autre champ.

XML

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD> 

PROHIBITEDVALUES

Définit une liste de valeurs interdites pour le champ. Si plusieurs ALLOWEDVALUES règles PROHIBITEDVALUES s’appliquent à un champ particulier, la liste complète des valeurs valides est l’intersection de toutes les listes de valeurs autorisées ( ou tout, s’il n’y a pas de listes de valeurs autorisées), moins , c’est-à-dire définir la différence , l’union de toutes les listes de valeurs interdites.

READONLY

Empêche la modification d’un champ. Vous souhaiterez peut-être appliquer cette règle dans certaines conditions. Par exemple, une fois qu’un élément de travail est fermé, vous souhaitez créer un champ en lecture seule pour conserver les données à des fins de création de rapports.
N’utilisez READONLY pas l’élément EMPTY , car EMPTY il crée également un champ en lecture seule. La combinaison de ces éléments peut produire des résultats incohérents.
En outre, vous pouvez faire apparaître un champ en lecture seule à partir du formulaire d’élément de travail à l’aide de l’attribut d’élément Control ReadOnly . Le champ peut être écrit par d’autres clients, mais pas via le formulaire d’élément de travail.

XML

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD> 

REQUIRED

Nécessite qu’un utilisateur spécifie une valeur pour le champ. Les utilisateurs ne peuvent pas enregistrer un élément de travail tant qu’ils n’ont pas affecté des valeurs à tous les champs obligatoires.

XML

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD> 

Sélectionner des listes

Les listes de sélection définissent les valeurs qu’un utilisateur peut ou ne peut pas choisir pour un champ String ou Integer. Les valeurs définies dans une liste de sélection s’affichent sur un formulaire d’élément de travail et l’éditeur de requête.

Processus d’héritage

Pour un processus hérité, les listes de sélection sont définies via la boîte de dialogue Modifier le champ.

Boîte de dialogue Modifier le champ

Description

Onglet Définition d’un champ de liste de sélection

Définit une liste de valeurs autorisées pour le champ. Les valeurs autorisées sont des valeurs disponibles pour la sélection dans une liste de champs sur les formulaires d’élément de travail et dans le générateur de requêtes. Vous devez sélectionner l’une de ces valeurs.

Cochez la case Autoriser les utilisateurs à entrer leurs propres valeurs dans l’onglet Options pour permettre aux utilisateurs de spécifier leurs propres entrées

Définit une liste de valeurs suggérées pour le champ. Les valeurs suggérées sont des valeurs disponibles pour la sélection dans une liste de champs sur les formulaires d’élément de travail et dans le générateur de requêtes. Vous pouvez également entrer d’autres valeurs dans la liste.

Processus XML local

Vous définissez des listes de sélection à l’aide d’éléments XML répertoriés dans le tableau suivant. Pour obtenir une structure de syntaxe et des exemples, consultez Définir des listes de sélection.

Vous pouvez combiner des listes et développer ou des listes de contrats. En outre, vous pouvez restreindre l’application de ces règles en fonction de l’appartenance au groupe de l’utilisateur actuel, comme décrit dans les restrictions de règle d’appartenance à l’utilisateur ou au groupe.

Élément XML

Description

ALLOWEDVALUES

Définit une liste de valeurs autorisées pour le champ. Les valeurs autorisées sont des valeurs disponibles pour la sélection dans une liste de champs sur les formulaires d’élément de travail et dans le générateur de requêtes. Vous devez sélectionner l’une de ces valeurs.

ALLOWEXISTINGVALUE

Définit le champ pour autoriser les valeurs existantes. Cet élément permet aux valeurs de champ qui existent déjà d’être utilisées, même si elles ne sont pas valides. Toutes les nouvelles valeurs de champ doivent être valides.

PROHIBITEDVALUES

Définit une liste de valeurs interdites pour le champ.

SUGGESTEDVALUES

Définit une liste de valeurs suggérées pour le champ. Les valeurs suggérées sont des valeurs disponibles pour la sélection dans une liste de champs sur les formulaires d’élément de travail et dans le générateur de requêtes. Vous pouvez également entrer d’autres valeurs dans la liste.

Champs d’identité et erreurs de validation

Pour éviter les erreurs de validation qui se produisent autrement lorsque les membres quittent l’équipe et ne sont plus inscrits en tant que contributeurs de projet, incluez l’élément ALLOWEXISTINGVALUE pour le champ Assigned To .

XML

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
      <HELPTEXT>The user who is working on this work item</HELPTEXT>
      <ALLOWEXISTINGVALUE />
      <VALIDUSER />
      <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
      <LISTITEM value="Active" />
      <LISTITEM value="[project]\Contributors" />
      </ALLOWEDVALUES>
      <DEFAULT from="field" field="System.CreatedBy" />
</FIELD>

Valeurs ou modifications de champ conditionnel

Les règles conditionnelles spécifient une action basée sur la valeur d’un champ égal ou non égal à une valeur spécifique, ou si une modification a été ou n’a pas été apportée à la valeur d’un champ spécifique. En règle générale, les règles conditionnelles sont appliquées en premier sur les règles inconditionnelles. Lorsque plusieurs règles conditionnelles ont la valeur true, l’ordre d’exécution est : When, WhenNot, WhenChanged, WhenNotChanged.

Processus d’héritage

Vous pouvez spécifier plusieurs règles conditionnelles par champ. Toutefois, vous ne pouvez spécifier qu’un seul champ de conduite par règle conditionnelle.

Condition héritée

Description

The value of ... (equals) [Quand]

Spécifie une ou plusieurs règles à appliquer au champ actif lorsqu’un autre champ a une valeur spécifique.

A change was made to the value of ... [WhenChanged]

Applique une ou plusieurs règles au champ actuel lorsque la valeur d’un champ spécifique est modifiée.

The value of ... (not equals) [WhenNot]

Applique une ou plusieurs règles au champ actuel quand un autre champ n’a pas de valeur spécifique.

No change was made to the value of ... [WhenNotChanged]

Applique une ou plusieurs règles au champ actif quand la valeur d’un champ spécifique n’est pas modifiée.

Action héritée

Description

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Spécifie l’action à entreprendre sur un champ spécifique.

Processus XML local

Les éléments XML suivants sont utilisés pour définir des conditions pour lesquelles d’autres règles sont évaluées. Vous pouvez spécifier plusieurs règles conditionnelles par champ. Toutefois, vous ne pouvez spécifier qu’un seul champ de conduite par règle conditionnelle. Vous ne pouvez pas imbriquer les règles conditionnelles. Les actions prises en charge pour chaque modèle de processus incluent celles répertoriées dans le tableau suivant.

Pour obtenir des exemples et une structure de syntaxe, consultez Affecter des valeurs et des règles basées sur des conditions. Vous pouvez restreindre l’application de ces règles en fonction de l’appartenance au groupe de l’utilisateur actuel, comme décrit dans les restrictions des règles d’appartenance aux utilisateurs ou aux groupes.

Élément XML

Utilisation

WHEN

Spécifie une ou plusieurs règles à appliquer au champ actif lorsqu’un autre champ a une valeur spécifique. L’élément parent définit le champ actif.
Lorsque le champ spécifié a la valeur spécifiée, les règles de cet élément sont appliquées au champ actif.

WHENCHANGED

Spécifie une condition dans laquelle appliquer une ou plusieurs règles au champ actif. Les règles s’appliquent au champ actuel lorsque la valeur d’un autre champ est modifiée dans une révision vers un élément de travail. L’élément parent définit le champ actif.

WHENNOT

Spécifie une condition dans laquelle appliquer une ou plusieurs règles au champ actif. Les règles s’appliquent au champ actuel lorsque la valeur d’un autre champ change. L’élément parent définit le champ actif.
Lorsque le champ spécifié ne contient pas la valeur spécifiée, les règles de cet élément sont appliquées au champ actif.

WHENNOTCHANGED

Spécifie une condition dans laquelle appliquer une ou plusieurs règles au champ actif. Les règles s’appliquent au champ actuel lorsque la valeur d’un autre champ n’est pas modifiée dans une révision d’un élément de travail. L’élément parent définit le champ actif.

Restrictions de règle d’appartenance aux utilisateurs ou aux groupes

Vous pouvez restreindre l’application d’une règle en fonction de l’appartenance de l’utilisateur actuel. Nous vous recommandons d’étendre la règle à un groupe de sécurité Azure DevOps, et non à un seul utilisateur, bien que vous puissiez spécifier ce dernier. Pour que la règle soit étendue à plusieurs groupes, vous devez créer un groupe Azure DevOps parent qui inclut l’ensemble de groupes que vous souhaitez utiliser.

Implémentation de processus

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 plus d’informations, consultez Les règles par défaut et le moteur de règles.

Processus d’héritage

Comme indiqué dans le tableau suivant, pour restreindre une règle en fonction de l’appartenance de l’utilisateur actuel, vous spécifiez l’une des deux conditions d’un processus hérité. Ces règles sont actives pour Azure DevOps 2020 et versions ultérieures.

S’applique à

Règle

Condition

Current user is a member of group ...
Current user is not member of group ...

Action

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

Processus XML local

Pour restreindre une règle en fonction de l’appartenance de l’utilisateur actuel, vous spécifiez les attributs ou not les for attributs de l’élément de règle. Vous spécifiez l’étendue de la règle. Pour que la règle soit étendue à plusieurs groupes, vous devez créer un groupe Azure DevOps parent qui inclut l’ensemble de groupes que vous souhaitez utiliser.

Scénario

Utilisation

Définir un champ requis uniquement pour un groupe spécifié

Permet for d’appliquer une règle à un groupe. Cet exemple nécessite que n’importe quel utilisateur du groupe Analystes juniors termine le deuxième champ Approbateur.

XML

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

Restreindre la modification d’un champ à un groupe d’utilisateurs

Permet not d’exclure un groupe d’une règle. Cet exemple définit le champ Description de triage comme étant en lecture seule pour tous, à l’exception des utilisateurs du groupe comité de triage.

XML

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

Définir un champ requis pour certains utilisateurs et non pour d’autres

Utilisez une combinaison et for not pour appliquer simultanément une règle à certains et non pour d’autres. Cet exemple définit La gravité comme champ obligatoire pour les utilisateurs du groupe Membres du projet, mais pas pour ceux du groupe Administrateurs de projet. Si un utilisateur se trouve dans les deux groupes, l’instruction for est appliquée et le champ est requis.

XML

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

Utiliser des jetons pour référencer des utilisateurs ou des groupes

Les champs de sélecteur d’identité ou de personnes peuvent accepter des valeurs qui référencent les utilisateurs et les groupes. Lorsque vous limitez une règle à un groupe, vous indiquez le domaine ou l’étendue du groupe. Pour certaines valeurs, vous pouvez utiliser des jetons.

Processus d’héritage

Voici quelques exemples de jetons :

• [ProjectName], comme [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], comme [fabrikam], [myorganization]
• [CollectionName], comme [fabrikam], [myorganization]

Pour en savoir plus sur les étendues disponibles pour votre projet ou votre organisation, accédez à la page Groupes d’autorisations> des paramètres>de projet ou groupes d’autorisations des>paramètres>de l’organisation, vous pouvez filtrer la liste en fonction des besoins. Par exemple, l’image suivante montre les quatre premières entrées d’une liste filtrée basée sur Azure DevOps. Pour plus d’informations, consultez Modifier les autorisations au niveau du projet ou Modifier les autorisations au niveau de la collection de projets.

Processus XML local

Voici quelques exemples de jetons :

• [Project], tel que [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approbateurs The [Project] token spécifie un groupe défini pour un projet. Cela peut correspondre à une équipe, à un groupe de sécurité par défaut ou personnalisé ou à un groupe Active Directory qui a été ajouté au projet.
• [GLOBAL], pour référencer un groupe délimité à une collection, par exemple [GLOBAL]\Administrateurs de collection de projets Utiliser [GLOBAL] pour référencer un groupe de sécurité délimité à une collection, tel que le groupe Administrateurs de collection de projets ou un groupe Windows ajouté à une collection. Par exemple :
  XML

  <FIELD name="Title">
      <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
  </FIELD>
  

• [Team Foundation] pour référencer un groupe au niveau du serveur, par exemple [Team Foundation]\Team Foundation Administrators Use [Team Foundation] pour référencer un groupe au niveau du serveur, tel qu’un groupe intégré ou un groupe Windows que vous ajoutez à un groupe au niveau du serveur. Par exemple :
  XML

  <FIELD name="Title">
      <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
  </FIELD>
  

• [DomainName] pour référencer un groupe au niveau du serveur, par exemple [Team Foundation]\Team Foundation Administrators Domain-qualified account, tel que celui indiqué dans l’exemple suivant, peut être utilisé pour référencer un utilisateur ou un groupe de domaine. Certaines règles prennent uniquement en charge les groupes et ne prennent pas en charge le référencement d’utilisateurs de domaine.
  XML

  <LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
  

Notes

[Project], [GLOBAL] et [Team Foundation] sont utilisés tel quel. Vous ne les remplacez pas par le nom du projet, de la collection ou du nom du serveur.

Pour en savoir plus sur les étendues disponibles pour votre projet ou collection, accédez à la page Groupes d’autorisations des>paramètres>de projet ou groupes d’autorisations des>paramètres>de regroupement. Filtrez la liste en fonction des besoins. Par exemple, l’image suivante montre les quatre premières entrées d’une liste filtrée basée sur Azure DevOps. Pour plus d’informations, consultez Modifier les autorisations au niveau du projet ou Modifier les autorisations au niveau de la collection de projets.

Tous les utilisateurs et groupes doivent être qualifiés par l’un de ces jetons. Par exemple, le code XML suivant n’est pas valide, car il ne qualifie pas le groupe spécifié avec un jeton valide.

XML

<FIELD name="Title">
    <READONLY for="Dev Team"/>
</FIELD>

Pour en savoir plus sur les groupes de sécurité par défaut, consultez Autorisations et groupes

Évaluation des règles

Les règles qui spécifient une condition basée sur l’appartenance de l’utilisateur ou du groupe à la modification d’un élément de travail sont évaluées de deux manières. Lorsque la règle est évaluée, l’application doit déterminer si la règle s’applique à l’utilisateur actuel en vérifiant si cet utilisateur est ou n’est pas membre du groupe spécifié.

• Lors de la modification de l’élément de travail à partir du portail web, de l’API REST ou de la commande Azure Boards , une demande adressée à l’ID Microsoft Entra ou à Active Directory est effectuée. Aucun problème ne se produit pour cette opération.
• Lors de la modification de l’élément de travail à partir de Visual Studio, Excel ou d’un autre outil personnalisé à l’aide du modèle objet client WIT, la demande d’évaluation de l’appartenance est basée sur un cache client. Le cache client n’est pas conscient des groupes Active Directory.

Notes

Visual Studio 2019 Team Explorer pour les projets utilisant GIT a été réécrit pour utiliser des API REST.

Pour éviter les problèmes liés à la mise à jour des éléments de travail des différents clients, spécifiez des groupes de sécurité Azure DevOps au lieu de groupes Active Directory. Vous pouvez facilement créer un groupe de sécurité Azure DevOps pour qu’il corresponde à un groupe Active Directory. Pour savoir comment, consultez Ajouter ou supprimer des utilisateurs ou des groupes, gérer des groupes de sécurité.

Notes

Le modèle d’objet client WIT est déconseillé. Depuis le 1er janvier 2020, il n’est plus pris en charge lors de l’utilisation d’Azure DevOps Services et d’Azure DevOps Server 2020.

Ordre dans lequel les règles sont évaluées

Les règles sont généralement traitées dans la séquence dans laquelle elles sont répertoriées. Toutefois, la séquence complète d’évaluation de toutes les règles n’est pas entièrement déterministe.

Cette section décrit le comportement et les interactions attendus lorsque vous appliquez des règles conditionnelles, de copie et par défaut.

Processus d’héritage

Les étapes suivantes montrent, dans la séquence correcte, les interactions effectuées par Azure DevOps et par l’utilisateur d’un formulaire d’élément de travail. Seules les étapes 1, 8 et 13 sont effectuées par l’utilisateur.

1. À partir d’un client Azure DevOps, tel que le portail web ou Visual Studio Team Explorer, un utilisateur crée un élément de travail ou modifie un élément de travail existant.

2. Renseignez les valeurs par défaut du champ. Pour tous les champs, appliquez les valeurs par défaut affectées au champ qui ne font pas partie d’une clause conditionnelle.

3. Copiez ou définissez des valeurs de champ. Pour tous les champs, appliquez toutes les règles pour copier une valeur ou définir la valeur d’un champ qui ne fait pas partie d’une clause conditionnelle.

4. Pour tous les champs avec une règle conditionnelle When qui correspond, appliquez des règles pour définir ou copier une valeur de champ.

5. Pour tous les champs avec une règle conditionnelle Quand non conditionnelle qui correspond, appliquez des règles pour définir ou copier une valeur de champ.

   Le système traite toujours Quand les règles sont antérieures aux règles lorsque ce n’est pas le cas.

6. Pour tous les champs dont les valeurs ont été modifiées depuis l’étape 1 et qui contiennent des règles De modification , appliquez des règles pour définir ou copier une valeur de champ.

7. Autoriser l’utilisateur à commencer à modifier.

8. L’utilisateur modifie une valeur de champ, puis déplace le focus à partir du champ.

9. Traitez les règles When pour ce champ qui correspondent à la nouvelle valeur.

10. Traitez les règles When Not pour ce champ qui correspondent à la nouvelle valeur.

11. Traitez les règles de modification de ce champ qui correspondent à la nouvelle valeur.

12. Renvoyer la possibilité d’édition à l’utilisateur.

13. L’utilisateur enregistre les modifications apportées au magasin de données.

14. Pour tous les champs, appliquez toutes Use the current time to set the value of ... les actions définies pour le champ directement ou indirectement sous une règle conditionnelle.

Processus XML local

Les règles sont généralement traitées dans la séquence dans laquelle elles sont répertoriées. Toutefois, lorsque vous utilisez les éléments WHEN, DEFAULT et COPY , des comportements supplémentaires peuvent s’appliquer. Les étapes suivantes montrent, dans la séquence correcte, les interactions effectuées par Azure DevOps et par l’utilisateur d’un formulaire d’élément de travail. Seules les étapes 1, 8 et 13 sont effectuées par l’utilisateur.

1. À partir d’un client Azure DevOps, tel que le portail web ou Visual Studio Team Explorer, un utilisateur crée un élément de travail ou modifie un élément de travail existant.

2. Renseignez les valeurs par défaut du champ. Pour tous les champs, appliquez toutes les règles DEFAULT spécifiées en dehors ou aux règles WHEN .

3. Copiez les valeurs de champ. Pour tous les champs, utilisez toutes les règles COPY qui ne sont pas des clauses WHEN .

4. Pour tous les champs avec une règle WHEN qui correspond, effectuez d’abord default, puis copiez les règles à l’intérieur.

5. Pour tous les champs avec une règle WHENNOT qui correspond, effectuez d’abord default, puis copiez les règles à l’intérieur.

   Le système traite toujours les règles WHEN avant les règles WHENNOT.

6. Pour tous les champs dont les valeurs ont été modifiées depuis l’étape 1 et qui contiennent des règles WHENCHANGED , effectuez d’abord default , puis copiez les règles à l’intérieur.

7. Autoriser l’utilisateur à commencer à modifier.

8. L’utilisateur modifie une valeur de champ, puis déplace le focus à partir du champ.

9. Déclenchez les règles WHEN pour ce champ qui correspondent à la nouvelle valeur.

10. Déclenchez toutes les règles WHENNOT pour ce champ qui correspondent à la nouvelle valeur.

11. Déclenchez toutes les règles WHENCHANGED pour ce champ qui correspondent à la nouvelle valeur.

12. Renvoyer la possibilité d’édition à l’utilisateur.

13. L’utilisateur enregistre les modifications apportées à la base de données.

14. Pour tous les champs, effectuez des opérations SERVERDEFAULT définies pour le champ directement ou indirectement sous une règle WHEN ou WHENNOT .

Entrées de séquence de touches et évaluation des règles

Le système définit une nouvelle valeur pour un champ chaque fois qu’un utilisateur entre une séquence de touches dans un champ via le formulaire élément de travail. Cela signifie qu’une règle conditionnelle peut se produire de manière inattendue chaque fois que les conditions préalables de la règle sont remplies.

Dans l’exemple XML suivant, le système vide MyCorp.SubStatus lorsque vous tapez « Approuvé à nouveau » dans le champ État, car la règle WHEN se produit dès que l’utilisateur tape la lettre « e » dans Approuvé, même si la valeur finale prévue n’est pas « Approuver ». Pour cette raison, réfléchissez soigneusement lorsque vous utilisez des règles conditionnelles.

XML

<FIELD refname="MyCorp.SubStatus" />
   <WHEN field="MyCorp.Status" value="Approve" >
      <EMPTY />
   </WHEN>
</FIELD>

Articles connexes

• Exemples de scénarios de règle
• Index des champs d’élément de travail
• Champs et attributs d’élément de travail
• Modifier les autorisations au niveau du projet
• Modifier les autorisations au niveau de la collection de projets
• Autorisations et groupes
• Processus hérité
  • Ajouter une règle personnalisée à un type d’élément de travail
  • Appliquer des règles aux états de flux de travail
• Processus XML local
  • Définir une valeur par défaut ou copier une valeur dans un champ
  • Définir des listes de sélection
  • Attribuer des valeurs et des règles basées sur des conditions