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 :
- L’état fermé est toujours contenu dans la catégorie d’état Terminé .
- La catégorie d’état Terminé n’est pas configurable et est associée à un seul état.
- Cet état fermé est toujours fermé pour les processus Agile et CMMI, et toujours Terminé pour les processus Scrum et De base.
- 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.
- 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.
- 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é.
- 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
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
Remarque
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
Masquer le champ ou rendre le champ en lecture seule ou obligatoire en fonction de l’état et de l’appartenance à l’utilisateur ou au groupe
En fonction de l’appartenance de l’utilisateur ou du groupe, définissez l’attribut de champ ou limitez une transition d’état
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.
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.
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.
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 .
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
Remarque
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é.
Remarque
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.
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.
À 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.
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.
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.
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.
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.
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.
Autoriser l’utilisateur à commencer à modifier.
L’utilisateur modifie une valeur de champ, puis déplace le focus à partir du champ.
Traitez les règles When pour ce champ qui correspondent à la nouvelle valeur.
Traitez les règles When Not pour ce champ qui correspondent à la nouvelle valeur.
Traitez les règles de modification de ce champ qui correspondent à la nouvelle valeur.
Renvoyer la possibilité d’édition à l’utilisateur.
L’utilisateur enregistre les modifications apportées au magasin de données.
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.