Applicare regole agli stati del flusso di lavoro (processo di ereditarietà)

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

Dopo aver aggiunto o modificato gli stati del flusso di lavoro per un tipo di elemento di lavoro, definire le regole che si applicano in base alla modifica dello stato del flusso di lavoro. L'aggiunta di regole agli stati del flusso di lavoro supporta gli scenari seguenti:

• Supporto di un processo di approvazione
• Impedire agli utenti non autorizzati di impostare uno stato non valido
• Impostare un campo obbligatorio o di sola lettura o un altro valore in base alle modifiche dello stato
• Limitare la transizione da uno stato a un altro
• Limitare o consentire transizioni di stato a utenti o gruppi specifici
• Gestire un processo di flusso di lavoro controllato, supportando i requisiti di controllo
• Automatizzare la chiusura degli elementi di lavoro padre

Prerequisiti

Per applicare regole agli stati del flusso di lavoro in Azure DevOps, sono necessarie autorizzazioni e livelli di accesso specifici:

• Autorizzazioni:

  • Essere un amministratore del progetto per gestire gruppi di sicurezza e autorizzazioni a livello di progetto, che include l'impostazione delle regole per gli stati del flusso di lavoro.
  • Disporre dell'autorizzazione Rilevamento elementi di lavoro, che consente di gestire l'area di rilevamento del lavoro, che può essere concessa ai membri del gruppo Project Administrators o tramite autorizzazioni specifiche.

• Livelli di accesso:

  • Disporre dell'accesso Basic , che in genere è sufficiente per la maggior parte degli utenti che devono gestire gli elementi di lavoro e applicare regole agli stati del flusso di lavoro.

Informazioni sulle regole del flusso di lavoro

La tabella seguente illustra i tre gruppi di regole del flusso di lavoro che è possibile definire:

1. Azioni standard:

   • Applicare quando viene creato un elemento di lavoro, in uno stato selezionato o spostato da uno stato a un altro.
   • Le azioni includono l'impostazione del valore di un campo, la sola lettura di un campo o l'impostazione di un campo obbligatorio.
   • È possibile specificare una o due condizioni e diverse azioni.

2. Limitazione delle transizioni di stato (gruppo 1):

   • Specificare una condizione che indica lo stato da cui è stato spostato un elemento di lavoro.
   • Definire azioni per limitare le transizioni da tale stato ad altri stati.

3. Limitazione delle transizioni di stato (gruppo 2):

   • Analogamente al primo gruppo, specificare una condizione che indica lo stato da cui è stato spostato un elemento di lavoro.
   • Definire azioni per limitare le transizioni da tale stato ad altri stati.

---

Condizione

Azioni supportate

---

Impostare il valore del campo o impostare il valore di sola lettura/obbligatorio in base allo stato

---

In base all'appartenenza a un utente o a un gruppo, impostare un attributo di campo o limitare una transizione di stato

---

Nota

Quando si personalizza un processo ereditato, tutti i progetti che usano tale processo riflettono automaticamente le personalizzazioni. Per garantire una transizione uniforme, è consigliabile creare un processo di test e un progetto, che consente di testare le personalizzazioni prima di implementarle a livello di organizzazione. Per altre informazioni, vedere Creare e gestire processi ereditati.

Informazioni sullo stato del flusso di lavoro e sui limiti delle regole

Le regole del flusso di lavoro vengono applicate quando si aggiungono o si modificano elementi di lavoro tramite una delle interfacce seguenti:

• Portale Web: modulo elemento di lavoro, aggiornamenti in blocco, aggiornamenti nella visualizzazione query
• Portale Web: Bacheca o Tabellone attività, spostare l'elemento di lavoro nella colonna
• Visual Studio 2017 e versioni precedenti, modulo dell'elemento di lavoro
• Formato di file CSV: importazione o aggiornamento bulk
• Excel: importazione o aggiornamento bulk
• API REST: aggiungere o modificare elementi di lavoro

La tabella seguente riepiloga i limiti delle regole e degli stati del flusso di lavoro per il processo di ereditarietà.

Oggetto	Limite di ereditarietà
Tipi di elementi di lavoro definiti per un processo	64
Stati del flusso di lavoro definiti per un tipo di elemento di lavoro	32
Regole definite per un tipo di elemento di lavoro	1024

Quando si definiscono gli stati e le regole del flusso di lavoro, seguire queste linee guida per ridurre al minimo i problemi di prestazioni:

• Limitare il numero di regole per un WIT: sebbene sia possibile creare più regole per un tipo di elemento di lavoro (WIT), più regole possono influire negativamente sulle prestazioni quando gli utenti aggiungono o modificano elementi di lavoro. Il sistema convalida tutte le regole associate ai campi per il tipo di elemento di lavoro quando gli utenti salvano gli elementi di lavoro. In alcuni casi, l'espressione di convalida delle regole potrebbe diventare troppo complessa per la valutazione di SQL.
• Limitare il numero di tipi di elementi di lavoro personalizzati: la riduzione del numero di tipi di elementi di lavoro personalizzati consente di mantenere prestazioni ottimali.

Definire una regola

Prima di definire una regola in base agli stati del flusso di lavoro, verificare che siano presenti gli elementi seguenti:

• Stati del flusso di lavoro: definire gli stati del flusso di lavoro come descritto in Personalizzare un flusso di lavoro.
• Campi personalizzati: se la regola richiede un campo personalizzato, aggiungerlo al tipo di elemento di lavoro come descritto in Aggiungere e gestire i campi.
• Gruppi di sicurezza: se la regola richiede a un gruppo di sicurezza di concedere o limitare le modifiche basate sull'appartenenza a utenti o gruppi, definire il gruppo di sicurezza come descritto in Aggiungere o rimuovere utenti o gruppi, gestire i gruppi di sicurezza.

Per altre informazioni sulla definizione delle regole, vedere Aggiungere una regola personalizzata.

Impostare il valore del campo o impostare il campo di sola lettura o obbligatorio

Con il primo raggruppamento di regole, è possibile specificare una o due condizioni e fino a 10 azioni per regola.

Esempio di verifica dell'approvazione del responsabile del team prima del lavoro attivo

In questo esempio, i team di sviluppo vogliono assicurarsi che nessuna storia utente venga risolto fino all'approvazione da parte di un responsabile del team. Gli stati predefiniti del flusso di lavoro vengono usati, con l'aggiunta di un campo personalizzato, Approvato da e un gruppo di sicurezza, gruppo di lead del team.

Stati predefiniti del flusso di lavoro

Requisiti delle regole

Per garantire l'approvazione prima del lavoro attivo, definire le regole seguenti:

• Richiedi che il campo Approvato per venga compilato quando lo stato passa da Nuovo a Attivo
• Limitare gli utenti che non si trovano nel gruppo di lead del team di compilare il campo Approvato da
• Deselezionare il campo Approvato da quando lo stato passa a Nuovo o Rimosso

Definizioni delle regole

I requisiti delle regole si traducono nelle quattro definizioni di regole seguenti.

---

Nome regola

Condizione

Azioni

---

Approvato da cancellato quando Nuovo

Quando A work item state changes to New

Allora Clear the value of Approved By

Approvato da cancellato quando rimosso

Quando A work item state changes to Removed

Allora Clear the value of Approved By

Approvato da sola lettura

Quando Current user is not member of group Team Leads Group

Allora Make read-only Approved By

Approvato da obbligatorio

Quando A work item state changes from New to Active

Allora Make required Approved By

---

Limitare le transizioni di stato

Quando si specifica la condizione , A work item state moved from ...è possibile specificare solo tale condizione. È possibile specificare fino a 10 azioni.

Esempio di limitazione delle transizioni di stato e dello stato approvato

Gli stati del flusso di lavoro seguenti sono definiti per la storia utente. Gli stati ereditati New, Resolved e Removed sono nascosti. Vengono invece usati gli stati Proposti, In Revisione e Taglia . Vengono inoltre definiti altri tre stati: ricerca, progettazione e approvazione. Questi stati devono seguire la sequenza come illustrato nell'immagine seguente.

Senza restrizioni, gli utenti possono passare da uno stato a qualsiasi altro stato, sia avanti che indietro all'interno della sequenza.

Requisiti delle regole

Per supportare un flusso di lavoro più controllato, il gruppo aziendale ha deciso di istituire regole che supportano le transizioni di stato in avanti e inversa seguenti nel tipo di elemento di lavoro User Story.

Provincia	Regola di transizione
Proposto	Può spostarsi solo in Ricerca e Taglio
Ricerca	Può passare solo a Progettazione e Taglia
Progettazione	Può passare solo a Ricerca, Approvato e Taglio
Approvato	Può passare solo a Progettazione, Attivo e Taglia
Attive	Può passare solo a In Review
In revisione	Può passare solo ad Attivo (altro lavoro trovato), Chiuso o Taglia
Chiusa	Può passare a Research, Design, Active, In Review (Consente ai casi in cui l'utente ha chiuso l'elemento di lavoro in errore)
Taglia	può passare solo a Proposta

Nota

Quando si limitano le transizioni di stato, tenere conto dei casi in cui un utente potrebbe spostare uno stato in errore. Assicurarsi che gli utenti possano ripristinare normalmente.

Inoltre, il gruppo aziendale vuole applicare le regole seguenti per i campi obbligatori:

• Richiedere che il campo Approvato per venga compilato quando lo stato passa da Approvato ad Attivo.
• Consentire solo agli utenti nel gruppo Responsabili approvazione autorizzati di compilare il campo Approvato da .
• Deselezionare il campo Approvato da quando lo stato passa a Taglia.
• Richiedi che il campo Criteri di accettazione venga compilato quando lo stato passa a Attivo.

Definizioni delle regole

Per implementare le restrizioni indicate in precedenza, l'amministratore del processo aggiunge un campo personalizzato Approvato per identità, un gruppo di sicurezza Responsabili approvazione autorizzati e le regole seguenti.

---

Nome regola

Condizione

Azioni

---

Stato proposto

Quando A work item state moved from Proposed

Allora Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed

Stato di ricerca

Quando A work item state moved from Research

Allora Restrict the state transition to Proposed
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed

Stato di progettazione

Quando A work item state moved from Design

Allora Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed

Stato approvato

Quando A work item state moved from Approved

Allora Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to In Review
E Restrict the state transition to Closed

Stato attivo

Quando A work item state moved from Active

Allora Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Closed

In Stato di revisione

Quando A work item state moved from In Review

Allora Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved

Stato chiuso

Quando A work item state moved from Closed

Allora Restrict the state transition to Proposed
E Restrict the state transition to Cut

Taglia stato

Quando A work item state moved from Cut

Allora Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed

Campi obbligatori per lo stato approvato

Quando A work item changes from Approved to Active

Allora Make required Acceptance Criteria
E Make required Approved By

Responsabili approvazione autorizzati

Quando Current user is not a member of Authorized Approvers

Allora Make read-only Approved By

Deselezionare il campo Approvato da

Quando A work item state changes to Cut

Allora Clear the value of Approved By

---

Verificare le restrizioni di transizione dello stato

Dopo aver definito le regole per il processo e aggiornato il progetto, aggiornare il browser. Verificare le operazioni tramite il modulo dell'elemento di lavoro e il browser.

Per le regole definite nella tabella precedente, selezionare i menu a discesa Stato. Aprire la scheda e assicurarsi di poter passare da uno stato a un altro.

Proposto	Ricerca	Progettazione	Approvata
Attive	In Revisione	Chiusi	Taglia

Limitare la transizione di stato in base all'appartenenza a utenti o gruppi

Quando si specifica una delle due condizioni in base all'appartenenza Current user is member of group ... a un utente o a un gruppo oppure Current user is not member of group ..., è possibile specificare una sola condizione. Inoltre, se si specifica l'azione Restrict the transition to state..., è possibile specificare solo un'azione.

Nota

Gli elementi di lavoro sono soggetti alle regole applicate. Le regole condizionali basate sull'appartenenza a utenti o gruppi vengono memorizzate nella cache per il Web browser. Se ci si trova limitato ad aggiornare un elemento di lavoro, potrebbe essere stata rilevata una di queste regole. Se si ritiene di aver riscontrato un problema che non si applica all'utente, vedere Problemi di memorizzazione nella cache di IndexDB nel modulo elemento di lavoro.

Automatizzare le transizioni di stato degli elementi di lavoro padre

Per automatizzare le transizioni di stato per gli elementi di lavoro padre basati sulle assegnazioni di stato degli elementi di lavoro figlio, vedere Automatizzare le transizioni di stato degli elementi di lavoro.

Automatizzare la riassegnazione in base alla modifica dello stato

Il tipo di elemento di lavoro del bug del processo Agile in precedenza aveva una regola che riassegnava il bug al relativo creatore. Questa regola è stata rimossa dal processo di sistema predefinito. È possibile ripristinare la regola o aggiungere una regola simile ad altri tipi di elemento di lavoro usando la condizione e l'azione seguenti:

Quando A work item state changes to viene risolto e quindiCopy the value from creato da a assegnato a.

Articoli correlati

• Aggiungere una regola personalizzata
• Memorizzazione nella cache dei moduli dell'elemento di lavoro
• Accedere ai log di controllo, esportarli e filtrarli
• Personalizzare un flusso di lavoro