Interroger par affectation ou modifications de workflow dans Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Les états dans le workflow prennent en charge le statut du travail à mesure qu’il passe d’un nouvel état à un état fermé ou terminé. Les champs de requête Kanban prennent en charge le suivi de l’état de travail à mesure qu’il passe d’une colonne ou d’un couloir à un autre sur le tableau Kanban.

Chaque workflow comprend un ensemble d’états, les transitions valides entre les états et les raisons de la transition de l’élément de travail à l’état sélectionné. Les états et raisons du workflow diffèrent selon les types d’éléments de travail et les processus par défaut utilisés pour créer votre projet.

La plupart des éléments de travail passent de l’état Nouveau, Actif ou Proposé à l’état Terminé ou Fermé. Quand un élément de travail passe d’un état à un autre, il peut également être réassigné à différents membres de l’équipe. Par exemple, un testeur peut créer un bogue qui est assigné à un autre membre de l'équipe au cours du triage. Quand ce dernier résout le bogue, celui-ci est réassigné au testeur qui l’a créé.

Par exemple, vous pouvez trouver tous les éléments de travail qui ont été fermés, puis réactivés. En spécifiant le champ Date de modification, vous pouvez vous concentrer sur les réactivations qui ont eu lieu aujourd’hui, hier ou la semaine dernière.

Query Editor filter for reactivated items.

Vous pouvez également utiliser les champs Activé par et Date d’activation ou d’autres champs de workflow.

Conseil

Tous les champs ne sont pas valides pour tous les types d’éléments de travail. Accédez aux champs de requête Workflow et Kanban pour l’ensemble de champs que vous pouvez inclure dans les requêtes et les types d’éléments de travail auxquels ils s’appliquent.

Si vous débutez dans la création de requêtes, consultez Utiliser l’éditeur de requête pour répertorier et gérer des requêtes.

Opérateurs et macros pris en charge

Les clauses de requête qui spécifient une identité ou un champ associé au workflow peuvent utiliser les opérateurs et macros répertoriés dans le tableau suivant. Pour en savoir plus sur le type de données de champ, consultez Champs de workflow et de tableau Kanban plus loin dans cet article.


Type de données

Opérateurs et macros pris en charge


Booléen1

= , <> , =[Field] , <>[Field]


DateTime

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], In, Not In, Was Ever
Macros : @Today, @Today +/- n valide avec n’importe quel champ DateTime


Identité

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was EverMacros : @Me valide pour tous les champs Identité


Texte unique (Chaîne)2

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was Ever


Utilisez les opérateurs In et Not In pour filtrer ou exclure au moins deux entrées de liste de sélection ou un ensemble d’éléments délimité. Utilisez les opérateurs In Group ou Not In Group pour filtrer les éléments qui appartiennent ou qui n’appartiennent pas à un groupe de catégories ou à un groupe de sécurité. Pour plus d’informations, consultez Champs de requête, opérateurs et macros.

Modèle de date et d’heure

Le modèle de date et d’heure que vous entrez pour les champs DateTime doit correspondre à celui que vous sélectionnez dans votre profil. Pour afficher ou modifier votre sélection, consultez Définir les préférences utilisateur, l’heure et les paramètres régionaux.

Time and Locale page, Date pattern optionsTime and Locale page, Time pattern options

Time and Locale page, Date pattern options

Requêtes basées sur l’identité

Utilisez la zone de recherche ou l’éditeur de requête pour trouver rapidement des éléments de travail en fonction d’une affectation effectuée à un champ Identité. En outre, vous pouvez filtrer les éléments de travail en fonction de qui a modifié, résolu ou fermé un élément de travail. En spécifiant une période, vous pouvez étendre votre requête encore plus loin, ce qui peut vous aider pour les performances.

Utilisez = pour rechercher les affectations actuelles, Was Ever pour répertorier des éléments en fonction des affectations passées et @Me pour définir une étendue à votre identité utilisateur.

Filtrer sur

Inclure ces clauses de requête


Éléments actifs qui m’ont été attribués

Assigned To @Me
And State = Active

Éléments fermés qui, à un moment donné, m’ont été attribués

Assigned To Was Ever @Me
And State = Closed

Témoignages d’utilisateurs actifs attribués à l’équipe web

Work Item Type = User Story
And State = Active
And Assigned To In Group [FabrikamFiber]\Web

Éléments que j’ai modifiés au cours des 30 derniers jours

Changed By = @Me And Changed Date >= @Today-30

Éléments non attribués (laissez la Valeur vide)

Assigned To = _


Requêtes d’appartenance à une équipe ou à un groupe

Pour filtrer par éléments assignés à un membre de groupe de sécurité ou d’équipe, utilisez l’opérateur In Group.

Screenshot of Query Editor, Filter based on assignment to a security group.

Vous pouvez utiliser les opérateurs In Group ou Not In Group pour filtrer une requête selon plusieurs valeurs qui appartiennent à un groupe, ou qui n’appartiennent pas à un groupe. Les exemples de groupes que vous pouvez spécifier incluent les éléments suivants :

  • Teams
  • Groupes de sécurité intégrés et personnalisés
  • Groupes de sécurité Microsoft Entra ID et Active Directory
  • Catégories d’élément de travail

Requêtes basées sur les modifications apportées au workflow

Vous utilisez les champs État, Raison et Raison de la résolution pour interroger les éléments en fonction des modifications apportées au workflow.

Filtrer sur

Inclure ces clauses de requête


Histoires résolues

Work Item Type = User Story
And State = Resolved

Histoires, bogues et tâches nouveaux ou actifs

Work Item Type In User Story,Bug,Task
And State In New,Active

Éléments supprimés car ils sont dupliqués

State= Removed
And Reason = Duplicate

Éléments ayant échoué aux tests d’acceptation

Resolved Reason = Acceptance tests fail

Éléments fermés au cours des 15 derniers jours

State = Closed
And Closed Date > @Today-15


Modifications de workflow et requêtes basées sur les identités

Vous pouvez rapidement trouver les éléments que vous avez modifiés, résolus ou fermés. Vous pouvez également trouver des éléments qui ont été modifiés par d’autres membres de l’équipe. Plusieurs champs, comme Créé par, Modifié par, Résolu par et Fermé par, sont renseignés en fonction des modifications apportées au workflow.

Filtrer sur

Inclure ces clauses de requête


Témoignages d’utilisateurs que j’ai fermés

Work Item Type = User Story
And Closed By = @Me

Éléments que j’ai résolus la semaine dernière

Resolved By = @Me
And Resolved Date >= Today-7


Interroger les modifications apportées à l’état de l’élément de travail

Pour répertorier les éléments de travail qui ont changé d’état dans une plage de dates spécifique, vous pouvez utiliser le champ Date de changement d’état pour affiner la recherche, puis ajouter des clauses pour les modifications apportées au champ État. L’image suivante en contient un exemple.

Screenshot of Query Editor, filter State Change Date and State fields.

Interroger les modifications apportées à un tableau Kanban

À l’aide des champs de requête Kanban (Colonne de tableau, Colonne de tableau effectuée et Couloir de tableau), vous pouvez répertorier les éléments de travail en fonction de leur état de flux sur le tableau Kanban. Vous pouvez également créer un graphique d’état ou de tendance en fonction de ces requêtes.

Vous pouvez répertorier des éléments en fonction du chemin de la zone d’équipe, et s’ils se trouvent dans une colonne Kanban personnalisée et un couloir spécifique. Si vous renommez une colonne ou un couloir, vous devez mettre à jour les filtres de requête pour qu’ils reflètent le nouveau nom. Pour plus d’idées, consultez ce billet de blog : Les nouveaux champs apportent la qualité de Kanban aux requêtes, et bien plus encore

Screenshot of Query Editor, filter on Kanban Board Column and Board Lane fields.

Remarque

Les requêtes sont désormais limitées au projet actuel par défaut. Cochez Interroger entre les projets pour rechercher les éléments de travail définis dans d’autres projets au sein de la collection.

Filtrer sur

Inclure ces clauses de requête


Témoignages utilisateur dans la colonne Code/En cours

Work Item Type = User Story
And Board Column = Code
And Board Column Done = False

Éléments dans le couloir d’accélération

Board Lane = Expedite

Éléments dans n’importe quel couloir dont l’étiquette contient « Test »

Board Lane Contains Test

Éléments qui se trouvaient dans la colonne « En cours de révision »

Board Column Was Ever In Review


Important

Les éléments de travail qui apparaissent sur plusieurs tableaux Kanban d’une équipe peuvent produire des résultats qui ne répondent pas à vos attentes, car chaque équipe peut personnaliser ses colonnes et couloirs de tableau Kanban. Les valeurs affectées aux champs Colonne du tableau, Colonne de tableau effectuée et Couloir de tableau Kanban peuvent différer de ce que vous attendez lorsqu’une autre équipe met à jour l’élément de travail à partir d’un autre tableau. Pour plus d’informations, consultez Ajouter, examiner et mettre à jour des éléments de travail dans Azure Boards.

Champs de workflow et de tableau Kanban

Les champs suivants sont utiles pour filtrer les requêtes. Certains de ces champs sont mis à jour à mesure qu’un élément de travail progresse d’un état à un autre. Ou ils sont mis à jour lorsque vous déplacez un élément de travail dans le tableau Kanban vers une autre colonne ou un autre couloir. Plusieurs de ces champs n’apparaissent pas dans le formulaire d’élément de travail, mais ils sont suivis pour les types d’éléments de travail répertoriés dans le tableau suivant.

Pour plus d’informations sur les attributs de champ, consultez Champs et attributs d’élément de travail.

Nom du champ

Description

Type d'élément de travail


Activé par 1, 2, 3

Nom du membre de l’équipe qui a modifié l’état d’un élément de travail à un état de catégorie En cours.

Nom du membre de l’équipe qui a modifié l’état d’un élément de travail de Nouveau à Actif ou réactivé un élément de travail une fois qu’il a été fermé, terminé ou effectué.

Nom de la référence=Microsoft.VSTS.Common.ActivatedBy
Type de données=Chaîne (Identité)

Bogue, Demande de modification, Épopée, Fonctionnalité, Problème, Élément de backlog de produit, Spécification, Révision, Risque, Étape partagée, Tâche, Cas de test, Récit utilisateur

Date d’activation 1, 3

Date et heure auxquelles l’élément de travail a été remplacé par un état de catégorie En cours.

Date et heure auxquelles l’élément de travail a été modifié de Nouveau à Actif ou réactivé une fois qu’il a été fermé, terminé ou effectué.

Nom de la référence=Microsoft.VSTS.Common.ActivatedDate
Type de données=DateTime

Tous

Attribué à 2

Attribué à 2, 3, 4

Nom du membre de l’équipe possédant actuellement l’élément de travail. Pour plus d’informations, consultez la Note 1 sur les champs de synchronisation et de nom de personne.

Nom de la référence=System.AssignedTo
Type de données=Chaîne (Identité)

Tous

Colonne de tableau

Affectation de colonne de tableau Kanban actuelle de l’élément de travail, par exemple : Actif, Fermé, Engagé, Effectué ou autre attribution de colonne personnalisée.

Nom de la référence=System.BoardColumn
Type de données=Chaîne

Catégorie d’exigence 4

Catégorie d’exigence 5

Colonne de tableau effectuée

Affectation actuelle de l’élément de travail à la colonne Kanban En cours (False) ou Effectué (True). Attribué uniquement lorsque les colonnes fractionnées sont activées pour une colonne de tableau Kanban.

Nom de la référence=System.BoardColumnDone
Type de données=booléen

Catégorie d’exigence 4

Catégorie d’exigence 5

Couloir de tableau

Affectation de couloir Kanban actuelle de l’élément de travail, par exemple : Par défaut, Accélération, Blocage ou autre affectation de couloir personnalisée. Nom de la référence=System.BoardLane
Type de données=Chaîne

Catégorie d’exigence 4

Catégorie d’exigence 5

Fermé par 1, 2

Fermé par 1, 2, 3

Nom du membre de l’équipe ayant défini l’état sur fermé ou terminé.

Nom de la référence=Microsoft.VSTS.Common.ClosedBy
Type de données=Chaîne (Identité)

Tous

Date de fermeture

Date et heure auxquelles un élément de travail a été fermé.

Nom de la référence=Microsoft.VSTS.Common.ClosedDate
Type de données=DateTime

Tous

Créé par 1, 2

Créé par 1, 2, 3

Nom du membre de l’équipe ayant créé l’élément de travail.

Nom de référence=’System.CreatedBy
Type de données=Chaîne (Identité)

Tous

Date de création

Date et heure auxquelles un élément de travail a été créé.

Nom de la référence=System.CreatedDate
Type de données=DateTime

Tous

Motif

Raison 3, 4

Raison pour laquelle l'élément de travail est dans l'état actuel. Chaque transition d’un état de workflow à un autre est associée à une raison correspondante.

Pour les modèles de processus XML locaux, les valeurs de raison sont définies dans la section WORKFLOW de la définition de type d’élément de travail à l’aide de l’élément REASON. Pour modifier les raisons définies, consultez Modifier le workflow pour un type d’élément de travail.

Nom de la référence=System.Reason
Type de données=Chaîne

Tout (sauf cas de test et étapes partagées)

Résolu par 1, 2

Résolu par 1, 2, 3

Nom du membre de l’équipe qui a modifié l’état d’un élément de travail à un état de catégorie Résolu.

Nom du membre de l’équipe qui a modifié l’état d’un élément de travail à un état de workflow Résolu ou effectué.

Nom de référence=Microsoft.VSTS.Common.ResolvedBy, Type de données=String (Identity)

Tous

Date de résolution

Date de résolution 1, 2

Date et heure auxquelles l’élément de travail a été remplacé par un état de catégorie Résolu.

Date et heure auxquelles l’élément de travail a été passé à l’état workflow Résolu ou terminé.

Nom de référence=Microsoft.VSTS.Common.ResolvedDate, Type de données=DateTime

Tous

Motif de résolution

Motif de résolution 3

Raison pour laquelle un élément de travail a été résolu. Par exemple, le code d'un récit utilisateur est complet ou le bogue a été résolu. Ce champ est en lecture seule et valide uniquement pour les éléments de travail de type Agile et CMMI.

Nom de la référence=Microsoft.VSTS.Common.ResolvedReason
Type de données=Chaîne

Tout (Agile, CMMI)

Révisé par

Nom du membre de l’équipe qui a répondu à une demande de révision de code et est catalogué dans la réponse à la révision du code.

Nom de la référence=Microsoft.VSTS.Common.ReviewedBy
Type de données=Chaîne (Identité)

Réponse de revue du code

State

État 3, 4

État actuel de l'élément de travail. Ce champ vous permet de mettre à jour le statut d'un élément de travail dès qu'il passe de l'état nouveau ou actif à l'état terminé ou fermé.

Pour modifier les états du workflow, consultez Personnaliser le workflow pour un processus.

Pour modifier les états du workflow, consultez les articles suivants :

Pour modifier les états de workflow, consultez Modifier le workflow pour un type d’élément de travail.

Nom de la référence=System.State
Type de données=Chaîne

Tous

Date de modification de l’état

Date et heures auxquelles la valeur du champ État a été modifiée.

Nom de la référence=Microsoft.VSTS.Common.StateChangeDate
Type de données=DateTime

Tous

Notes

  1. Consultez Champs Date et Identité.
  2. Par défaut, le serveur synchronise les champs de nom de personne ou basés sur l'identité définis par le système avec Active Directory ou Microsoft Entra ID. Ces champs sont les suivants : Activé par, Assigné à, 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 de la page Sécurité des paramètres de collection. Voir configurer Active Directory ou Microsoft Entra ID.
  3. Consultez Champs Activated By/Date et Resolved By/Date.
  4. La catégorie d’exigence s’applique à tous les types d’éléments de travail qui apparaissent dans le backlog du produit et le tableau Kanban, et peut inclure ceux 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 des types d’éléments de travail.

Notes

Même si vous ajoutez un champ lié au tableau, comme Colonne de tableau ou Couloir de tableau, à un formulaire d’élément de travail, vous ne pouvez pas modifier le champ à partir du formulaire.

  1. Consultez Champs Date et Identité.

  2. Par défaut, le serveur synchronise les champs de nom de personne ou basés sur l'identité définis par le système avec Active Directory ou Microsoft Entra ID. Ces champs sont les suivants : Activé par, Assigné à, 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 de la page Sécurité des paramètres de collection. Voir configurer Active Directory ou Microsoft Entra ID.

    Pour les déploiements locaux, vous pouvez activer ou désactiver la synchronisation d’un champ de nom de personne à l’aide de l’outil en ligne de commande witadmin changefields. Vous pouvez également synchroniser les champs de noms de personnes 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 l’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 rapportables sont exportées vers l’entrepôt de données et peuvent être incluses dans des rapports Excel ou SQL Server. Pour Azure DevOps local, utilisez la commande witadmin changefield pour modifier l’attribut pouvant être déclaré pour un champ.

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

  5. La catégorie d’exigence s’applique à tous les types d’éléments de travail qui apparaissent sur le backlog du produit et le tableau Kanban. 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 des types d’éléments de travail.

Notes

Même si vous ajoutez un champ lié au tableau, comme Colonne de tableau ou Couloir de tableau, à un formulaire d’élément de travail, vous ne pouvez pas modifier le champ à partir du formulaire.

Sélecteur de personnes

Le champ Affecté à est pris en charge par la fonctionnalité de sélecteur de personnes. Par exemple, lorsque vous choisissez le champ Affecté à dans un formulaire d’élément de travail, le sélecteur de personnes est activé. Comme le montre l'image suivante, il vous suffit de commencer à saisir le nom de l'utilisateur que vous souhaitez sélectionner et de rechercher jusqu'à ce que vous trouviez une correspondance. Les utilisateurs que vous avez sélectionnés apparaissent automatiquement dans la liste. Pour sélectionner des utilisateurs que vous n’avez pas sélectionnés précédemment, entrez leur nom entier ou recherchez dans l’annuaire complet.

Screenshot of the <span class=@mention dans Discussion montrant le sélecteur de personnes." />

Pour les organisations qui gèrent leurs utilisateurs et groupes à l'aide de Microsoft Entra ID ou d'Active Directory, les sélecteurs de personnes prennent en charge la recherche de tous les utilisateurs et groupes ajoutés à AD, et pas seulement des utilisateurs et groupes ajoutés au projet.

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

Champs de date et d’identité

Plusieurs champs de date et d’identité sont définis en fonction des états ou des transitions de workflow. Certains champs, comme Créé par et Date de création sont définis par le système lorsqu’un élément de travail est ajouté. D’autres champs, comme Date de fermeture et Fermé par, sont définis via la définition de workflow du type d’élément de travail. En outre, les types d’éléments de travail personnalisés peuvent avoir d’autres règles définies qui influencent les affectations de champs de date et d’identité.

Modèle de date et d’heure

Le modèle de date et d’heure que vous entrez pour les champs DateTime doit correspondre à celui que vous sélectionnez dans votre profil. Pour afficher ou modifier votre sélection, consultez Définir les préférences utilisateur, l’heure et les paramètres régionaux.

Time and Locale page, Date pattern optionsTime and Locale page, Time pattern options

Time and Locale page, Date pattern options

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égissent les valeurs des champs sélectionnés. Ici, les champs Date de résolution, Résolu par, Date de ferme, Fermé par, Date d’activation et Activé par sont définis sur EMPTY quand 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 Bogue, 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 d’activation 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 d’activation, Résolu par et Date de résolution) lorsqu’une modification se produit en fonction des états de catégorie de workflow 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 workflow sont mappés aux catégories d’état, consultez Utilisation des états de workflow et des catégories d’état dans les backlogs et tableaux.

Notes

La logique régissant les champs décrits ici s’applique à Azure DevOps Services, Azure DevOps Server 2020.1 et versions ultérieures.

Étant donné que ces champs référencent les catégories d’état de workflow, les états de workflow 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 workflow pour un processus.

Informations complémentaires :

  • Les champs sont mis à jour chaque fois qu’un élément de travail change à partir 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 une transition vers l’arrière, comme passer d’un état Résolu à un état Actif, le système efface les valeurs des champs Résolu par/Date de résolution. Si vous passez d’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 régis par des règles système. Toute valeur que vous tentez de définir est écrasée.

API REST

Pour interagir par programmation avec des requêtes, consultez l’une de ces ressources d’API REST :