Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
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 afin de comprendre les points suivants :
- Comment le système applique les règles qui sont générées automatiquement
- Restrictions imposées à la définition des règles personnalisées sur les champs système
- Les différents types de règles personnalisées que vous pouvez appliquer
- Méthode d’évaluation des règles
- Différence entre les règles définies pour un processus d’héritage et celles définies pour un processus XML sur site
- Pourquoi vous devez réduire au minimum 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 afin de répondre aux attentes de votre entreprise.
Conseil
Réduisez le nombre de règles que vous définissez pour un type d’élément de travail. 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 dynamiquement l’ensemble complet des règles de transition d’état « n’importe quel vers n’importe quel » pour chaque type d’élément de travail personnalisé et chaque état personnalisé ajouté à un workflow. Une transition de n’importe quel état vers n’importe quel autre état est valide.
En ce qui concerne les processus XML sur site, vous devez spécifier les transitions valides dans la section WORKFLOW de la définition de type d’élément de travail.
Transitions d’état et règles de champ Par/Date
Les champs Par/Date correspondent à Créé Par/Date, Activé Par/Date, Résolu Par/Date et Clôturé Par/Date.
Pour les processus hérités, ces champs sont automatiquement définis ou effacés lorsque vous faites passer un élément de travail d’un état à un autre. Les champs Modifié Par/Date ne sont pas inclus car ils sont mis à jour à chaque enregistrement d’un é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 Clôturé est toujours contenu dans la catégorie d’état Terminé.
- La catégorie d’état Terminé ne peut pas être configurée, et elle est associée à un seul état.
- Cet état Clôturé est toujours Clôturé pour les processus Agile et CMMI, et indique toujours Terminé pour les processus Scrum et Essentiel.
- La génération automatique de ces règles est affectée par les paramètres régionaux, car la condition de la règle contient le nom de l’É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 ne sont spécifiées que pour les types d’éléments de travail qui incluent ces champs. Il est possible qu’un type d’élément de travail ne comprenne pas un ou plusieurs de ces champs.
- Ces règles sont nécessaires lorsqu’un type d’élément de travail comporte des états personnalisés ou lorsqu’il s’agit d’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 sur site.
Les états du workflow sont associés à des catégories d’états afin de faciliter le workflow 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 du champ « Date de changement d’état »
Ces règles sont techniquement beaucoup plus simples que les règles « Clôturé par »/« Date de clôture », car elles ne dépendent d’aucun état particulier. Pour tout type de tâche, les mêmes règles s’appliquent systématiquement. Elles doivent être générées automatiquement car certains types d’éléments de travail OOB ne contiennent pas le champ Date de modification d’état. Ainsi, 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 Closed By/Closed Date s'appliquent ici aussi.
Règles personnalisées
Toutes les règles personnalisées sont optionnelles. Pour un processus hérité, vous spécifiez une règle qui se compose d’une condition et d’une action. Pour un processus XML sur site, vous spécifiez des règles pour un champ ou dans le workflow.
Il n’y a pas de correspondance biunivoque entre les deux processus. Parfois, 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, comme FROZEN, MATCHNOTSAMEAS, ne sont pas pris en charge dans le processus hérité.
Notez les points suivants :
- Les règles sont toujours appliquées, non seulement lorsque vous interagissez avec le formulaire, mais également lorsque vous utilisez d’autres outils. Par exemple, le fait de définir un champ comme étant en lecture seule permet non seulement d'appliquer la règle sur le formulaire de l'élément de travail, mais aussi via l'API et le module complémentaire Excel Azure DevOps Server.
- Les entrées de processus héritées spécifient les conditions et les actions nécessaires pour créer 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’attribution de valeurs qui sont la somme de deux autres champs ou l’exécution d’autres calculs mathématiques. Cependant, vous pouvez trouver une solution adaptée à vos besoins via l’extension TFS Aggregator (Web Service) Marketplace. Voir aussi Rollup de travail et d'autres champs.
- Vous pouvez trouver d’autres solutions pour appliquer des règles personnalisées aux champs à l’aide d’extensions Marketplace, telles que l’extension de bibliothèque de contrôles de formulaire d’élément de travail.
Composition des règles
Pour un processus hérité, chaque règle se compose de deux parties : les conditions et les actions. Les conditions définissent les circonstances qui doivent être réunies pour que la règle s’applique. Les actions définissent les opérations à réaliser.
- Vous ne pouvez pas avoir plusieurs règles à l’aide des mêmes conditions et actions sur le même type d’élément de travail.
- Pour la plupart des règles, vous pouvez spécifier au maximum deux conditions et 10 actions par règle.
- Toutes les règles personnalisées doivent remplir toutes les conditions pour pouvoir être exécutées.
À titre d’exemple, vous pouvez rendre un champ obligatoire en fonction de la valeur attribuée à l’état et à un autre champ. Par exemple :
(Condition) When a work item State is
Actif
(Condition) And when the value of
Zone de valeur = Affaires
(Action) Then make required
Points d’histoire
Note
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 workflow.
La table suivante récapitule les actions disponibles avec les conditions sélectionnées.
Condition
Actions prises en charge
Définir la valeur du champ ou le rendre obligatoire ou en lecture seule
Restreindre une transition 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
Que se passe-t-il si un trop grand nombre de règles sont définies ?
Une seule expression SQL est définie par projet pour valider les éléments de travail dès leur création ou leur mise à jour. Cette expression augmente avec le nombre de règles spécifiées 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 hausse du nombre de sous-expressions. Les règles imbriquées, qui s’appliquent uniquement lors d’une transition ou en fonction de la valeur d’un autre champ, entraînent l’ajout de conditions supplémentaires à une instruction IF. Une fois que l’expression a atteint une certaine taille ou complexité, SQL ne peut plus l’évaluer et génère une erreur. La suppression de certains types d’élément de travail ou 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 relatives aux éléments de travail n'existent pas en tant que collection unique. Les règles sont en réalité générées de manière dynamique et fusionnées à partir de différentes sources de données. La logique de fusion est simple : consolider les règles identiques, mais ne pas supprimer les règles contradictoires.
Règles de contournement
Généralement, 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 auxquels l’autorisation au niveau du projet Ignorer les règles lors de la mise à jour des éléments de travail a été attribuée peuvent enregistrer des éléments de travail sans que les règles ne soient évaluées.
Les règles peuvent être contournées de deux manières. La première consiste à utiliser Éléments de travail - mettre à jour l’API REST et à définir le paramètre bypassRules sur true. La seconde consiste à utiliser le modèle objet client, en initialisant en mode bypassrules (initialiser WorkItemStore avec WorkItemStoreFlags.BypassRules).
Champs système et règles personnalisées
Les champs système comportent des noms de référence System.Name, par exemple System.Title et System.State.
Les champs système suivants doivent avoir une valeur : ID de zone, Date de modification, Date de création, Créé par, État et Motif.
Le moteur de règles limite la définition des conditions ou des actions aux champs système, sauf dans les cas suivants :
- Vous pouvez définir les champs État et Motif en lecture seule.
- Vous pouvez appliquer la plupart des règles aux champs Titre, Attribué à, Description et Modifié par.
Si un champ n'apparaît pas dans le menu déroulant de l'interface utilisateur des règles pour le processus d'héritage, c'est qu'il s'agit d'une règle de contournement. Par exemple, si vous essayez de définir le champ Chemin d’accès à la zone (System.AreaPath) en lecture seule en fonction d’une condition, le champ Chemin d’accès à la zone ne peut être sélectionné. Même si vous parvenez à spécifier un champ système, le moteur de règles peut vous empêcher d’enregistrer la règle.
Règles par défaut et règles de copie
Les règles par défaut et de copie modifient les valeurs des champs des éléments de travail. Ils définissent le comportement et les contraintes d’exécution, tels que la spécification des valeurs par défaut, l’effacement des champs, l’obligation de définir les champs, etc.
Vous pouvez limiter l’application de ces règles selon l’appartenance du groupe de l’utilisateur actuel, comme décrit dans Restrictions relatives aux règles d’appartenance à un utilisateur ou à un groupe.
La plupart de ces actions peuvent être appliquées en sélectionnant n’importe quelle condition.
Action du processus hérité
Description
Copy the value from...
Spécifie un autre champ contenant une valeur à copier dans le champ actuel.
Clear the value of...
Efface toutes les valeurs contenues dans le champ.
Use the current time to set the value of ...
Définit l’heure d’un champ en fonction du paramètre horaire de l’utilisateur actuel.
Règles de contrainte
Les règles de contrainte limitent les modifications de la valeur d’un champ. Elles définissent les états valides pour un élément de travail. Chaque contrainte s’applique sur un seul champ. Les contraintes sont évaluées sur le serveur lors de l’enregistrement des éléments de travail, et si une contrainte n’est pas respectée, l’opération d’enregistrement est rejetée.
Vous pouvez limiter l’application de ces règles selon l’appartenance du groupe de l’utilisateur actuel, comme décrit dans Restrictions relatives aux règles d’appartenance à un utilisateur ou à un groupe.
La plupart de ces actions peuvent être appliquées en sélectionnant n’importe quelle condition.
Action du processus hérité
Description
Hide the field...
Disponible si une condition d’appartenance au groupe est sélectionnée.
Spécifie de ne pas afficher le champ dans le formulaire d’élément de travail, supprimant ainsi la possibilité pour l’utilisateur actuel de modifier la valeur du champ.
Make read-only
Empêche toute modification d’un champ. Vous pouvez appliquer cette règle dans certaines conditions. Par exemple, après la clôture d’un élément de travail, vous souhaitez rendre un champ en lecture seule afin de conserver les données à des fins de reporting.
Pour spécifier que le champ par défaut est en lecture seule, indiquez-le dans la boîte de dialogue Modifier le champ, dans l’onglet Options.
Make required
Oblige l’utilisateur à spécifier une valeur pour le champ. Les utilisateurs ne peuvent pas enregistrer un élément de travail tant qu’ils n’ont pas attribué de valeurs à tous les champs obligatoires.
Pour spécifier que le champ par défaut est obligatoire, indiquez-le dans la boîte de dialogue Modifier le champ, dans l’onglet Options.
Listes de choix
Les listes de sélection définissent les valeurs qu’un utilisateur peut ou ne peut pas choisir pour un champ de type chaîne ou entier. Les valeurs définies dans une liste de sélection apparaissent dans un formulaire d’élément de travail et dans l’éditeur de requête.
En ce qui concerne 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 les valeurs disponibles pour la sélection dans une liste de champs sur les formulaires de work item et dans le générateur de requêtes. Vous devez sélectionner l’une de ces valeurs.
Cochez la case Autoriser les utilisateurs à saisir leurs propres valeurs dans l’onglet Options afin 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 les valeurs disponibles pour la sélection dans une liste de champs sur les formulaires de work item et dans le générateur de requêtes. Vous pouvez également saisir d’autres valeurs dans la liste.
Valeurs ou modifications conditionnelles des champs
Les règles conditionnelles spécifient une action en fonction de la valeur d’un champ égal ou non à une valeur spécifique, ou si une modification a été apportée ou non à la valeur d’un champ spécifique. En général, les règles conditionnelles sont appliquées avant les règles inconditionnelles. Lorsque plusieurs règles conditionnelles sont évaluées comme vraies, l'ordre d'exécution est le suivant : When, WhenNot, WhenChanged, WhenNotChanged.
Vous pouvez spécifier plusieurs règles conditionnelles par champ. Cependant, vous ne pouvez spécifier qu’un seul champ déterminant par règle conditionnelle.
Condition héritée
Description
The value of ... (equals) [Quand]
Spécifie une ou plusieurs règles à appliquer au champ actuel lorsqu’un autre champ a une valeur spécifique.
A change was made to the value of ... [QuandChangé]
Applique une ou plusieurs règles au champ actuel quand 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 lorsqu’un autre champ ne contient pas de valeur spécifique.
No change was made to the value of ... [WhenNotChanged]
Applique une ou plusieurs règles au champ actuel 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 à effectuer sur un champ spécifique.
Restrictions relatives aux règles d’appartenance à un utilisateur ou à un groupe
Vous pouvez restreindre l’application d’une règle selon l’appartenance du utilisateur actuel. Nous vous recommandons d’appliquer la règle à un groupe de sécurité Azure DevOps plutôt qu’à un utilisateur unique, bien que vous puissiez spécifier ce dernier. Pour que la règle s’applique à plusieurs groupes, vous devez créer un groupe Azure DevOps parent qui inclut l’ensemble des groupes que vous souhaitez utiliser.
Processus d’implémentation
Conseil
Pour éviter tout problème d’évaluation des règles, spécifiez les groupes de sécurité Azure DevOps et non les groupes de sécurité Microsoft Entra ID ou Active Directory. Pour en savoir plus, consultez Règles par défaut et moteur de règles.
Comme indiqué dans la table suivante, pour restreindre une règle en fonction de l’appartenance de l’utilisateur actuel, vous devez spécifier l’une des deux conditions suivantes pour un processus hérité. Ces règles sont actives pour Azure DevOps 2020 et les 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 d’identité ou de sélection de personnes peuvent accepter des valeurs qui font référence à la fois à des utilisateurs et à des groupes. Lorsque vous limitez une règle à un groupe, vous indiquez le domaine ou la portée du groupe. Vous pouvez utiliser des jetons pour certaines valeurs.
Voici quelques exemples de jetons :
- [ProjectName], par exemple [Fabrikam], [FabrikamFiber], [MyProject]
- [OrganizationName], par exemple [fabrikam], [myorganization]
- [CollectionName], par exemple [fabrikam], [myorganization]
Pour en savoir plus sur les portées disponibles pour votre projet ou votre organisation, accédez à la page Paramètres du projet>Autorisations>Groupes ou Paramètres de l’organisation>Autorisations>Groupes, où vous pourrez filtrer les résultats selon ce que vous recherchez. Par exemple, l’image suivante montre les quatre premières entrées d’une liste filtrée en fonction d’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 de règle
Les règles qui spécifient une condition basée sur l’appartenance de l’utilisateur ou du groupe à l’utilisateur qui modifie 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 non 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 requête est envoyée à Microsoft Entra ID ou à Active Directory. Aucun problème n’est survenu durant cette opération.
- Lorsque vous modifiez l’élément de travail à partir de Visual Studio, Excel ou un autre outil personnalisé à l’aide du modèle d’objet client WIT, la demande d’évaluation de l’appartenance est basée sur un cache client. Le cache client ne reconnaît pas les groupes Active Directory.
Note
Visual Studio 2019 Team Explorer pour les projets utilisant GIT a été réécrit afin d’utiliser les API REST.
Pour éviter tout problème lié à la mise à jour des éléments de travail par des utilisateurs à partir de différents clients, spécifiez des groupes de sécurité Azure DevOps plutôt que des groupes Active Directory. Vous pouvez facilement créer un groupe de sécurité Azure DevOps correspondant à un groupe Active Directory. Pour savoir comment procéder, consultez Ajouter ou supprimer des utilisateurs ou des groupes, et gérer des groupes de sécurité.
Note
Le client WIT OM est obsolescent. Depuis le 1er janvier 2020, cette fonctionnalité n’est plus prise en charge avec Azure DevOps Services et Azure DevOps Server 2020.
Ordre dans lequel les règles sont évaluées
Les règles sont généralement traitées dans l’ordre dans lequel elles sont répertoriées. Cependant, la séquence complète pour l’évaluation de toutes les règles n’est pas entièrement déterministe.
Cette section décrit le comportement et les interactions attendus quand des règles conditionnelles, de copie et par défaut sont appliquées.
Les étapes suivantes montrent, dans l’ordre correct, 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 réalisé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 nouvel élément de travail ou modifie un élément existant.
Renseignez les valeurs par défaut du champ. Pour tous les champs, appliquez toutes les valeurs par défaut attribuées au champ qui ne font pas partie d’une clause conditionnelle.
Copiez ou définissez les valeurs de champ. Pour tous les champs, appliquez toutes les règles permettant de copier une valeur ou de 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 « When Not » qui correspond, appliquez des règles pour définir ou copier une valeur de champ.
Le système traite toujours les règles When avant les règles When Not.
Pour tous les champs dont les valeurs ont été modifiées depuis l’étape 1 et qui contiennent des règles When changed, appliquez des règles afin de définir ou de copier une valeur de champ.
Autoriser l’utilisateur à éditer.
L’utilisateur modifie la valeur d’un champ, puis quitte ce champ.
Traitez toutes les règles When pour ce champ qui correspondent à la nouvelle valeur.
Traitez toutes les règles When Not pour ce champ qui correspondent à la nouvelle valeur.
Traitez toutes les règles When Changed pour ce champ qui correspondent à la nouvelle valeur.
Retourner la possibilité d’édition à l’utilisateur.
L’utilisateur enregistre les modifications apportées au magasin de données.
Pour tous les champs, appliquez toutes les actions
Use the current time to set the value of ...définies pour le champ, directement ou indirectement, sous une règle conditionnelle.