Interroger par affectation ou modifications de workflow

• Niveaux d’accès :
  • Pour afficher et exécuter des requêtes partagées : membre du projet.
  • Pour ajouter et enregistrer une requête partagée : au moins un accès de base (Basic).
• Autorisations :Contribuer définie sur Autoriser (Allow) pour le dossier auquel vous souhaitez ajouter une requête. Par défaut, le groupe des contributeurs ne dispose pas de cette autorisation.

• Niveaux d’accès:
  • Pour consulter et exécuter des requêtes partagées : Membre du projet (Project Member).
  • Pour ajouter et enregistrer une requête partagée : au moins un accès de base (Basic).
• Autorisations :Contribuer définie sur Autoriser (Allow) pour le dossier auquel vous souhaitez ajouter la requête. Par défaut, le groupe de contributeurs ne dispose pas de cette autorisation.

1. Consultez Champs Date et Identité.

2. Par défaut, le serveur synchronise les champs de nom de personne ou d’identité définis par le système avec Active Directory ou Microsoft Entra ID. Ces champs sont les suivants : Activé par, Affecté à, Fermé par, Créé par et Résolu par. Vous pouvez accorder l’accès à un projet en ajoutant des groupes de sécurité que vous avez créés dans Active Directory ou Microsoft Entra ID ou en ajoutant des comptes à des groupes existants ou personnalisés définis à partir du paramètre de collection page Sécurité. Voir la configuration de Active Directory ou Microsoft Entra ID.

   Pour les déploiements locaux, vous pouvez activer ou désactiver la synchronisation pour un champ de nom de personne à l’aide de l’outil en ligne de commande witadmin changefields. Vous pouvez également synchroniser des champs de nom de personne personnalisés en spécifiant l’attribut syncnamechanges. Consultez Gérer les champs d’élément de travail et Informations de référence sur l’élément FIELD (Définition).

3. Champ reportable avec attribut défini sur Dimension. Valide uniquement lorsque la collection est configurée pour prendre en charge le modèle XML local. Les données reportables sont exportées vers l’entrepôt de données et peuvent être incluses dans les rapports Excel ou SQL Server. Pour Azure DevOps local, utilisez la commande witadmin changefield pour modifier l’attribut reportable pour un champ.

4. Champ indexé. L’activation de l’indexation pour un champ peut augmenter les performances de la recherche d’éléments de travail dont les requêtes spécifient ce champ. Pour Azure DevOps local, utilisez la commande witadmin indexfield pour modifier l’attribut d’index d’un champ.

5. La catégorie Exigence s’applique à tous les types d’éléments de travail qui apparaissent dans le backlog produit et sur le tableau. La catégorie inclut ces éléments ajoutés à la catégorie de bogues en fonction du paramètre d’équipe pour Afficher les bogues sur les tableaux et les backlogs. Pour plus d’informations sur les catégories de types d’éléments de travail, consultez Utiliser des catégories pour regrouper les types d’éléments de travail.

Pour limiter l’étendue des identités disponibles pour la sélection à seulement ces utilisateurs ajoutés au projet, vous pouvez le faire à l’aide du groupe Project-Scoped Utilisateurs. Pour plus d’informations, consultez : Gérer votre organisation, Limiter la recherche d’identités et la sélection.

Modifications d’état

L’exemple de syntaxe XML suivant illustre les règles qui peuvent être définies pour un type d’élément de travail qui régit les valeurs des champs sélectionnés. Ici, les champs Date résolue, Résolu par, Date fermée, Fermé par, Date activée, et Activé par sont définis sur EMPTY lorsqu'une valeur d'état est définie sur "Nouveau". Les affectations de valeur d’état sont évaluées en premier, et les affectations de transition sont évaluées ensuite.

   <WORKFLOW>
      <STATES>
        <STATE value="New">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Active">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Resolved">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Closed" />
      </STATES>

Affectations de transition Activé par et Date d’activation

Lorsque les transitions suivantes se produisent pour un élément de travail 'Bug', les affectations suivantes sont effectuées dans les champs Activé par et Date d'activation :

<TRANSITION from="" to="New">
<TRANSITION from="New" to="Active">
<TRANSITION from="New" to="Resolved">
<TRANSITION from="New" to="Closed">
<TRANSITION from="Resolved" to="Active">
<TRANSITION from="Closed" to="Active">

<FIELDS>
   <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
       <COPY from="currentuser" />
           <VALIDUSER />
           <REQUIRED />
    </FIELD>
    <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
        <SERVERDEFAULT from="clock" />
   </FIELD>
</FIELDS>

Et lorsque les transitions suivantes se produisent pour l’élément de travail Bogue :

<TRANSITION from="Active" to="New">
<TRANSITION from="Active" to="Closed">
<TRANSITION from="Resolved" to="Closed">

Ensuite, les champs Activé par et Date activée sont définis sur READONLY.

<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
   <READONLY />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
   <READONLY />
</FIELD>

Champs "Activé par/Date" et "Résolu par/Date"

Le système met à jour ces champs :Activé par, Date activée, Résolu paret Date résolue— lorsqu’une modification se produit en fonction des états de catégorie de flux de travail correspondants. Lorsque l’état du workflow passe à une catégorie d’état En cours, Activé par et Date d’activation sont mis à jour. Lorsque l’état du workflow passe à une catégorie d’état Résolu, Résolu par et Date de résolution sont mis à jour.

Pour en savoir plus sur la façon dont les états de flux de travail correspondent aux catégories d’état, consultez Comment les états de flux de travail et les catégories d’état sont utilisés dans Backlogs et Boards.

Étant donné que ces champs référencent les catégories d’état de flux de travail, les états de flux de travail personnalisés que vous ajoutez sont référencés lors de la mise à jour des champs. Pour en savoir plus sur la personnalisation, consultez Personnaliser le flux de travail pour un processus.

Remarques supplémentaires :

• Les champs sont mis à jour chaque fois qu’un élément de travail passe d’un état de catégorie autre que celui défini. Par exemple, si vous mettez à jour un élément de travail de Nouveau vers Résolu, les champs Résolu par/Date de résolution sont mis à jour. Toutefois, si vous effectuez une mise à jour à partir de Fixe et Prêt pour les tests, qui sont dans le même état de catégorie, les champs Résolu par/Date de résolution ne sont pas mis à jour.
• Lorsque vous effectuez un retour en arrière, par exemple en passant d'un état Résolu à un état Actif, le système efface les valeurs des champs Résolu par/Date résolue. Si vous êtes passé de Actif à Nouveau, le système efface les valeurs des champs Activé par/Date d'activation.
• Ne modifiez pas manuellement les valeurs de ces champs. Il s’agit de champs système qui sont régis par des règles système. Toute valeur que vous tentez de définir est écrasée.