Exemples de scénarios de règles personnalisées
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Cet article fournit des exemples de définitions de règles personnalisées. Toutes les règles personnalisées sont définies pour un type d’élément de travail. Des exemples sont fournis pour les modèles hérités et locaux de processus XML.
Avant d’ajouter des règles personnalisées, lisez les règles et l’évaluation des règles et ajoutez une règle à un type d’élément de travail (processus d’héritage).
Définir un champ obligatoire dépendant
Vous pouvez spécifier qu’un champ n’est requis que lorsqu’un autre champ contient une valeur spécifique. Dans l’exemple suivant, lorsqu’un client signale un problème, le champ Client Signalé personnalisé est défini sur True et le champ Gravité devient obligatoire. Si le problème n’est pas signalé par un client, une valeur pour le champ Gravité n’est pas requise.
Effacer la valeur d’un champ dépendant
L’exemple suivant illustre la définition d’une règle personnalisée pour effacer la valeur des points d’histoire lorsqu’une modification est apportée à la date de début.
Définir une valeur de champ dépendante
Les exemples suivants illustrent comment mapper les valeurs du champ Taille en fonction de la valeur sélectionnée pour le champ personnalisé, champ Taille du tee-shirt.
La liste de choix taille du tee-shirt se compose de quatre valeurs Small, Medium, Large et X-Large. Quatre règles personnalisées sont définies pour affecter le champ Taille lorsque le champ Taille du tee-shirt est remplacé par une valeur spécifique. Pour simplifier l’utilisation, la valeur par défaut de la taille du tee-shirt est petite.
Boîte de dialogue Modifier le champ Taille du tee-shirt
Règle personnalisée
Quatre règles personnalisées
Exiger une valeur de champ lors des modifications d’état
L’exemple suivant montre comment vous pouvez exiger la spécification du champ Travail restant lorsque l’état du flux de travail de tâche passe à Actif.
Effacer la valeur d’un champ lors de la fermeture de l’état
Pour automatiser l’effacement du champ Travail restant lors de la fermeture d’une tâche, définissez une règle personnalisée comme indiqué.
Restreindre la création d’éléments de travail par un groupe
Une règle personnalisée qui limite la transition vers la catégorie d’état proposé d’un type d’élément de travail interdit efficacement la création d’éléments de travail de ce type. En appliquant la règle à un groupe spécifique, vous empêchez efficacement ce groupe de créer des éléments de travail de ce type.
La règle personnalisée suivante empêche une équipe de projet de créer des éléments de travail en tant que catégorie d’état proposée est mappée à l’état Nouveau flux de travail.
Restreindre la modification des éléments de travail par un groupe
Pour un processus d’héritage, vous pouvez empêcher les utilisateurs de modifier un élément de travail en définissant l’autorisation refuser pour un groupe sur un chemin d’accès à la zone. Pour un processus XML local, vous pouvez placer des restrictions sur chaque état de flux de travail d’un groupe qui les empêche d’enregistrer l’élément de travail dans n’importe quel état.
Il n’est pas possible de définir une règle personnalisée qui limite la modification des éléments de travail d’un type spécifique. Vous ne pouvez spécifier que la restriction par état. Si l’utilisateur ne modifie pas l’état, il peut modifier d’autres champs, sauf si tous les champs sont effectués en lecture seule pour le groupe.
Au lieu de cela, si vous souhaitez restreindre un groupe d’utilisateurs à modifier la sélection d’éléments de travail de n’importe quel type, vous pouvez affecter ces éléments de travail à un chemin d’accès de zone. Définissez un groupe de sécurité, puis définissez des restrictions pour modifier les éléments de travail pour ce chemin d’accès de zone pour ce groupe, comme illustré dans l’image suivante. Pour plus d’informations, consultez Définir les autorisations et l’accès pour le suivi du travail, Créer des nœuds enfants et modifier des éléments de travail sous un chemin d’accès de zone
Restreindre les transitions d’état
Pour les processus hérités, les transitions d’état any-to-any sont automatiquement définies. Cela permet aux utilisateurs d’avancer l’état du flux de travail de nouveau à terminé, mais également de reculer en cas de besoin. Lorsque vous définissez des règles personnalisées pour restreindre une transition, gardez à l’esprit que si un utilisateur fait une erreur lors de la mise à jour du flux de travail, il se peut qu’il ne soit pas en mesure de le corriger. Par exemple, ils peuvent mettre à jour l’état en déplaçant une carte d’élément de travail vers une étape ultérieure sur la carte, mais pas la déplacer vers l’arrière.
Conseil
Envisagez de restreindre une transition d’état pour certains utilisateurs, mais pas tous. De cette façon, si un utilisateur fait une erreur, il peut demander à un autre membre de l’équipe de réinitialiser la valeur d’état pour contourner la restriction.
Avant de définir des règles de transition d’état, passez en revue les règles et l’évaluation des règles, les règles générées automatiquement et la façon dont les états de flux de travail et les catégories d’état sont utilisés dans les backlogs et les tableaux.
Restreindre la modification des éléments de travail fermés
Selon vos processus métier, vous pouvez empêcher les utilisateurs de continuer à modifier ou mettre à jour des éléments de travail qui ont été fermés ou terminés. Vous pouvez ajouter des règles aux types d’éléments de travail pour empêcher les utilisateurs de rouvrir les éléments de travail fermés.
Pour le processus hérité, vous pouvez ajouter une règle qui limite la transition d’état. Par exemple, la règle suivante limite la transition de la fermeture aux deux autres États, Nouveau et Actif.
Remarque
La A work item state moved from ... condition est disponible pour Azure DevOps Server 2020 et versions ultérieures.
Remarque
Selon l’action de règle que vous spécifiez, le bouton Enregistrer du formulaire d’élément de travail peut être désactivé ou un message d’erreur s’affiche lorsqu’un utilisateur restreint tente de modifier l’élément de travail.
Masquer ou restreindre la modification d’un champ en fonction d’un utilisateur ou d’un groupe
Lorsque vous sélectionnez ou Current user is a member of group... Current user is not a member of group..., vous pouvez masquer un champ, créer un champ en lecture seule ou rendre un champ requis.
Par exemple, la condition suivante indique que le champ Justification est masqué pour les membres qui n’appartiennent pas au groupe Fabrikam Fibre\Voice.
Remarque
Les éléments de travail sont soumis aux règles qui leur sont appliquées. Les règles conditionnelles basées sur l’appartenance d’un utilisateur ou d’un groupe sont mises en cache pour votre navigateur web. Si vous vous trouvez limité à la mise à jour d’un élément de travail, vous avez peut-être rencontré l’une de ces règles. Si vous pensez que vous avez rencontré un problème qui n’est pas traité ici, consultez Problèmes de mise en cache IndexDB du formulaire d’élément de travail.
Restreindre la modification de certains champs en fonction d’un utilisateur ou d’un groupe
Vous pouvez personnaliser les types d’éléments de travail pour restreindre les personnes pouvant modifier un champ spécifique pour un type d’élément de travail.
Remarque
Pour Azure DevOps Server 2019 et versions antérieures, vous ne pouvez restreindre la modification des éléments de travail qu’en fonction d’un utilisateur ou d’un groupe avec le modèle de processus XML local.
À l’aide de l’une des deux conditions suivantes, vous pouvez définir des champs sélectionnés requis pour un utilisateur d’un groupe de sécurité ou qui ne sont pas membres d’un groupe de sécurité.
current user is a member of a group...current user is not a member of a group...
Conseil
Pour éviter les problèmes d’évaluation des règles qui peuvent survenir, spécifiez des groupes de sécurité Azure DevOps et non des groupes de sécurité Microsoft Entra ou Active Directory. Pour plus d’informations, consultez Les règles par défaut et le moteur de règles.
Par exemple, vous pouvez définir le titre ou les champs État en lecture seule pour sélectionner des utilisateurs ou des groupes.
Par exemple, le champ Priorité , pour le type d’élément de travail User Story, devient en lecture seule pour les membres du groupe Fabrikam Fibre\Voice. Lorsqu’un utilisateur de ce groupe ouvre un récit utilisateur, il ne peut pas modifier la valeur sur le champ Priorité.
