Appliquer une règle à un champ d'élément de travail

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 valeurs des différents 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.

Tous ces éléments de règles peuvent être définis dans la définition FIELD d'une définition de type d'élément de travail, soumise à certaines restrictions pour les champs système. En outre, à l'exception de HELPTEXT, vous pouvez indiquer que ces règles doivent entrer en vigueur lors de la transition d'un flux de travail ou en tant qu'éléments enfants dans un élément FIELD (flux de travail global).

Vous pouvez définir n'importe quelle combinaison de règles pour un champ, soumise aux contraintes décrites dans cette rubrique.

Les règles de champ sont un composant dont vous disposez pour personnaliser le suivi des éléments de travail. Pour plus d'informations, consultez Personnaliser les objets de suivi de travail pour prendre en charge les processus de votre équipe.

Pour plus d'informations sur la modification des champs ou sur l'ajout de règles de champ à un fichier de définition de type d'élément de travail, consultez Modifier ou ajouter un champ pour prendre en charge les requêtes, les rapports et le flux de travail.

Texte d'aide

Vous pouvez personnaliser le texte d'aide ou le texte de l'info-bulle qui apparaît lorsqu'un utilisateur pointe sur un champ affiché dans un formulaire d'élément de travail. Vous pouvez personnaliser et localiser le texte d'aide pour le même champ qui apparaît dans différents types d'éléments de travail et différents projets d'équipe. Le texte d'aide ne peut pas contenir plus de 255 caractères Unicode.

L'exemple suivant illustre l'assignation du texte d'aide à un champ Business Justification personnalisé :

<FIELD name=”Business Justification” refname="Fabrikam.BusinessJustification" type="String">
<HELPTEXT>Only required when you set the Urgencyfield to Need Immediately. </HELPTEXT>
</FIELD>

Pour fournir aux utilisateurs un guide qui dépasse la limite de 255 caractères, consultez Fournir du texte d'aide, des liens hypertexte ou du contenu Web sur un formulaire d'élément de travail.

Règles des listes de choix

Les règles des listes de choix définissent les valeurs qu'un utilisateur peut choisir ou non pour un champ de chaîne. Les valeurs définies dans une liste de choix s'affichent dans un formulaire d'élément de travail et l'Éditeur de requêtes. Vous pouvez combiner des listes, ainsi que les développer ou les réduire. Vous pouvez également utiliser les attributs for et not pour appliquer ou ignorer ces règles, en fonction de la personne qui modifie l'élément de travail.

Pour obtenir des exemples d'utilisation des listes de choix, consultez Définir les listes de choix.

Règles d'assignation de valeurs

Les règles de valeur d'assignation définissent les contraintes et le comportement d'exécution, notamment la spécification des valeurs par défaut, l'effacement des champs, la demande de définition de champs, entre autres. Vous pouvez appliquer ou ignorer ces règles en fonction de la personne qui modifie l'élément de travail à l'aide des attributs for et not.

Effacer, définir par défaut ou copier une valeur, ou forcer des valeurs pour correspondre à un modèle

Ces règles prennent en charge la définition de valeurs par défaut, la copie de valeurs d'un champ à un autre ou l'application d'une valeur de champ pour correspondre à un modèle imposé.

Pour obtenir la structure de la syntaxe et des exemples, consultez Définir une valeur par défaut ou copier une valeur dans un champ.

Exiger, définir en lecture seule et restreindre les valeurs assignées à un champ

Ces règles indiquent des restrictions sur la spécification ou la modification de la valeur d'un champ.

Pour obtenir la structure de la syntaxe, consultez Référence de tous les éléments XML FIELD.

Limiter les personnes autorisées à créer ou modifier un élément de travail

Vous pouvez contrôler les personnes autorisées à créer ou modifier un élément de travail en appliquant l'élément VALIDUSER aux champs de noms de personne. Lorsque vous spécifiez cet élément, vous indiquez l'utilisateur ou le groupe d'utilisateurs qui peut être assigné en tant que valeur pour le champ. Vous pouvez définir cet élément pour prendre en charge l'attribut group facultatif, qui exige que la personne qui est assignée au champ soit un membre direct ou indirect du groupe que vous spécifiez. Par défaut, tous les membres du groupe Team Foundation Valid Users peuvent être spécifiés dans le champ.

L'élément VALIDUSER est valide uniquement pour les types de champs de chaîne. Vous pouvez autoriser ou limiter l'application de la règle à l'utilisateur qui modifie l'élément de travail en spécifiant un utilisateur ou un groupe pour les attributs for ou not, respectivement.

<VALIDUSER group="groupName" for="userName" not="userName" />

Vous ne pouvez utiliser la règle VALIDUSER que lorsque vous faites référence aux champs de noms de personne. Les champs système suivants sont des exemples de champs de noms de personne :

• Activated By (System.ActivatedBy)

• Assigned To (System.AssignedTo)

• Authorized As (System.AuthorizedAs)

• Changed By (System.ChangedBy)

• Closed By (System.ClosedBy)

• Created By (System.CreatedBy)

Outre les champs système, vous pouvez créer un champ de chaîne personnalisé et l'utiliser comme champ de noms de personne. Vous pouvez également synchroniser les champs de noms de personne personnalisés avec Active Directory (indiquez syncnamechanges="true").

Les champs d'éléments de travail n'effectuent pas de distinction entre les identités des utilisateurs de différents domaines. Par conséquent, Fabrikam\ctsoapo et Contoso\ctsoapo sont traités comme étant le même utilisateur lorsqu'ils sont entrés dans un champ qui utilise la règle VALIDUSER.

Règles conditionnelles

Les règles conditionnelles vous permettent de spécifier le moment où un ensemble de règles est appliqué à un champ parent. Vous pouvez définir des conditions selon qu'une valeur spécifiée est assignée (ou non) à un autre champ ou lorsqu'un autre champ est modifié (ou non). Vous pouvez inclure des règles des listes de choix et de valeur d'assignation dans un élément de règle conditionnelle.

Vous pouvez spécifier plusieurs règles conditionnelles par champ. Toutefois, vous ne pouvez spécifier qu'un seul champ pilote par règle conditionnelle. Vous ne pouvez pas imbriquer des règles conditionnelles. Pour obtenir la structure de la syntaxe et des exemples, consultez Assigner les valeurs et les règles conditionnelles.

Appliquer ou ignorer les règles en fonction de la personne qui crée ou modifie l'élément de travail

Vous pouvez faire en sorte qu'une règle de liste de choix ou de valeur d'assignation s'applique ou non à un groupe d'utilisateurs à l'aide des attributs for ou not. Limitez la portée de la règle à un groupe. Pour que la règle porte sur plusieurs groupes, vous devez créer un groupe TFS parent qui inclut l'ensemble des groupes à utiliser.

• Faites en sorte qu'un champ ne soit requis que pour un groupe spécifié :

  Utilisez for pour appliquer une règle à un groupe. Cet exemple exige que tout utilisateur dans le groupe Junior Analysts renseigne le champ Second Approver.

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

• Limitez la modification d'un champ à un groupe d'utilisateurs :

  Utilisez not pour exclure un groupe d'une règle. Cet exemple définit le champ Triage Description comme étant en lecture seule pour tous les utilisateurs sauf ceux du groupe Triage Committee.

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

• Faites en sorte qu'un champ soit requis pour certains utilisateurs et non pour d'autres :

  Utilisez une combinaison de for et not pour appliquer une règle à certains utilisateurs et non à d'autres simultanément. Cet exemple définit Severity comme un champ requis pour les utilisateurs du groupe Project Members, mais pas pour ceux du groupe Project Admins.

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

  Comme Deny est prioritaire sur Allow, si un utilisateur fait partie des deux groupes, l'instruction « not » est appliquée et le champ n'est pas requis.

Utiliser des jetons pour référencer des groupes

Lorsque vous limitez une règle à un groupe, vous devez indiquer le domaine ou la portée du groupe. Pour certaines valeurs, vous pouvez utiliser des jetons.

Les champs de noms de personne peuvent accepter des valeurs qui font référence à la fois aux utilisateurs et aux groupes. Les attributs de champs, for et not, s'appliquent aux groupes. Vous pouvez utiliser les jetons suivants quand vous spécifiez des valeurs pour ces éléments.

• Limitez à un projet d'équipe – [Project] :

  Le jeton [Project] permet de spécifier un groupe qui est défini pour un projet d'équipe. Ce groupe peut correspondre à une équipe, un groupe TFS intégré, tel que le groupe [Project]\Contributors, un groupe TFS personnalisé que vous créez au niveau du projet ou un groupe Windows que vous avez ajouté à un groupe TFS. Par exemple :

  • Équipe : [Project]\Fabrikam Team

    Lorsque vous créez une équipe, un groupe TFS est créé, qui contient les membres assignés à l'équipe.

  • Groupe de projet d'équipe : [Project]\Contributors

  • Groupe Windows ajouté à un projet d'équipe : [Project]\ Triage Committee

  Conseil : vous pouvez afficher une liste des groupes valides en ouvrant la page Sécurité dans le contexte d'administration TWA (Team Web Access).

• Limitez à une collection de projets – [Nom_Collection] :

  Utilisez [Nom_Collection] pour faire référence à un groupe TFS à portée de collection, tel que le groupe Administrateurs de la collection de projets ou un groupe Windows que vous ajoutez à une collection. Exemple :

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

• Limitez à une instance de serveur – [GLOBAL] :

  Utilisez le jeton [GLOBAL] pour faire référence à un groupe TFS à portée de serveur, tel qu'un groupe intégré ou un groupe Windows que vous ajoutez à un groupe de niveau serveur. Exemple :

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

• Spécifiez un groupe ou un compte qualifié de domaine :

  Un nom de compte qualifié de domaine, tel que celui affiché dans l'exemple suivant, peut être utilisé pour faire référence à un groupe ou utilisateur de domaine. Notez que certaines règles ne prennent en charge que les groupes et non la référence aux utilisateurs de domaine.

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

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.

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

Q et R

Q : Quelles règles peuvent être appliquées aux champs système ?

R : Les champs système ont des noms de référence System.Nom, par exemple System.Title et System.State. TFS limite la personnalisation de ces champs, à l'exception des instances suivantes :

• La règle HELPTEXT peut être assignée à tous les champs.

• La règle READONLY peut être assignée aux champs State et Reason.

• La plupart des règles peuvent être assignées aux champs système Title, Assigned To, Description ou Changed By.

Q : Comment éviter les erreurs de validation sur les champs de noms de personne ?

R : Pour éviter les erreurs de validation qui sinon se produisent lorsque des membres quittent l'équipe et ne sont plus inscrits comme collaborateurs de projet, ajoutez l'élément ALLOWEXISTINGVALUE pour le champ Assigned To.

<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>

Q : Existe-t-il un moyen de définir une liste de choix multisélection ?

R : Cette fonctionnalité n'est pas prise en charge en mode natif. Toutefois, vous pouvez adapter le code source fourni dans ce projet CodePlex : Contrôles personnalisés pour le suivi des éléments de travail TFS.

Q : Comment modifier les champs State et Reason ?

R : Les champs State et Reason sont définis dans la section WORKFLOW de la définition du type d'élément de travail. Vous pouvez spécifier la plupart des règles de champ pour qu'elles s'appliquent à un champ pendant une modification d'état, la sélection d'une raison ou pour une transition spécifique. Pour plus d'informations, consultez Modifier le flux de travail pour un type d'élément de travail.

Q : Où dois-je appliquer une règle de champ ?

R : Lorsque vous voulez qu'une règle s'applique à un champ pendant toute la vie de l'élément de travail, indiquez-le dans la définition FIELD. Par exemple, un champ qui est requis pour un bogue nouveau et actif reste requis tant que le bogue n'est pas fermé.

Sinon, indiquez une règle à évaluer uniquement pendant une modification d'état. Ces règles sont définies dans la section WORKFLOW sous les éléments STATE, REASON ou TRANSITION. Toutes les règles, à l'exception de HELPTEXT, peuvent être appliquées dans un élément FIELD (flux de travail).

Les règles de champ sont additives. Autrement dit, vous pouvez spécifier quatre ensembles de règles pour le même champ qui seront toutes évaluées par le moteur de règles d'éléments de travail.

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

  "MyField Value" != NULL

• Les règles spécifiques à l'état se limitent à une instance d'élément de travail quand elle se trouve dans un certain état. Une règle spécifique à l'état est appliquée quand la condition suivante est satisfaite :

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

• Les règles spécifiques à la transition que vous spécifiez pour une transition donnée se limitent à un élément de travail qui est l'objet d'une certaine transition. Ces règles sont appliquées lorsque les conditions suivantes sont réunies :

  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 donnée se limitent à une raison particulière pour une transition particulière. Elles sont traitées lorsque les conditions suivantes sont réunies :

  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 Active.

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

Q : Comment les règles sont-elles évaluées ?Quel ordre est appliqué ?

R : Les règles sont généralement traitées dans l'ordre dans lequel elles sont répertoriées. Toutefois, lorsque vous utilisez les éléments WHEN*, DEFAULT et COPY, d'autres comportements peuvent s'appliquer.

Vous pouvez vous faire une idée du mode d'évaluation des règles lorsque vous appliquez plusieurs règles à un champ. Le mode d'évaluation des règles n'est pas entièrement déterministe. Cette section décrit le comportement prévu et les interactions quand vous utilisez les règles WHEN*, DEFAULT et COPY.

Les étapes suivantes indiquent, dans l'ordre approprié, les interactions effectuées par TFS 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 Team Foundation, tel que Visual Studio, Team Explorer, Team Web Access ou Team Explorer Everywhere, un utilisateur crée un élément de travail ou modifie un élément de travail existant.

2. Renseignez les valeurs par défaut des champs. Pour tous les champs, utilisez toutes les règles DEFAULT qui sont extérieures aux règles WHEN*.

3. Copiez les valeurs de champ. Pour tous les champs, utilisez toutes les règles COPY qui sont extérieures aux clauses WHEN*.

4. Pour tous les champs avec une règle WHEN correspondante, utilisez d'abord DEFAULT, puis COPY à l'intérieur.

5. Pour tous les champs avec une règle WHENNOT correspondante, utilisez d'abord DEFAULT, puis COPY à l'intérieur.

   TFS 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, utilisez d'abord DEFAULT, puis COPY à l'intérieur.

7. Autorisez l'utilisateur à commencer la modification.

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

9. Déclenchez toutes 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. Redonnez à l'utilisateur la possibilité d'apporter des modifications.

13. L'utilisateur enregistre les modifications dans la base de données.

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

Q : Comment les entrées au clavier dans un formulaire affectent-elles l'évaluation des règles ?

R : Le système définit une nouvelle valeur pour un champ chaque fois qu'un utilisateur entre une combinaison de touches dans un champ via le formulaire d'élément de travail de l'interface utilisateur. Cela signifie qu'une règle conditionnelle peut se produire de façon inattendue chaque fois que les conditions préalables de la règle sont réunies.

Dans l'exemple XML suivant, SubStatus est vidé quand vous tapez « Approved Again » dans le champ Status, car la règle WHEN* se produit dès que l'utilisateur tape la lettre « e » dans Approved, même si la valeur finale voulue n'est pas « Approve ». Pour cette raison, réfléchissez bien quand vous utilisez des règles conditionnelles.

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

Q : Comment faire en sorte qu'un champ contienne une valeur qui est la somme de deux autres champs ?

R : Cette fonctionnalité n'est pas prise en charge en mode natif pour l'instant.

Q : Quand définir des règles de champ avec un flux de travail global ?

R : Utilisez un flux de travail global uniquement lorsque vous êtes chargé de tenir à jour de nombreux champs avec les mêmes définitions et règles sur plusieurs projets d'équipe. Comme les listes globales, l'utilisation d'un flux de travail global peut minimiser le travail requis lorsque vous devez mettre à jour les définitions de champ. Pour plus d'informations, consultez Personnaliser le flux de travail global.

Voir aussi

Concepts

Référence de tous les éléments XML WITD

Autres ressources

Modifier ou ajouter un champ pour prendre en charge les requêtes, les rapports et le flux de travail