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, è possibile definire una o più regole applicate a seconda della modifica dello stato del flusso di lavoro. L'aggiunta di regole agli stati del flusso di lavoro supporta gli scenari seguenti:

• Supportare un processo di approvazione
• Impedire agli utenti non autorizzati di impostare uno stato non valido
• Apportare un campo obbligatorio o di sola lettura o 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 del flusso di lavoro controllato per supportare i requisiti di controllo
• Automatizzare la chiusura degli elementi di lavoro padre

Esaminare questo articolo per comprendere come definire le regole che si applicano quando si modifica uno stato del flusso di lavoro.

• Informazioni sui tipi di regole del flusso di lavoro
• Limiti e procedure consigliate per lo stato e le regole del flusso di lavoro
• Impostare un valore di campo o impostare un campo di sola lettura o obbligatorio in base alla selezione dello stato
• Limitare le transizioni di stato
• Limitare o consentire transizioni di stato a utenti o gruppi specifici
• Automatizzare le transizioni di stato degli elementi di lavoro padre

Importante

Questo articolo si applica alle versioni Azure DevOps Services e Azure DevOps Server 2019 e versioni successive. Per personalizzare qualsiasi progetto definito in una raccolta per TFS 2018 o versioni precedenti, vedere Modello di processo XML locale.

Regole del flusso di lavoro

La tabella seguente indica i tre gruppi di regole del flusso di lavoro che è possibile definire. Il primo gruppo applica azioni standard quando viene creato un elemento di lavoro, in uno stato selezionato o viene spostato da uno stato a un altro. Queste azioni standard impostano il valore di un campo o rendono un campo di sola lettura o obbligatorio. In questo gruppo è possibile specificare una o due condizioni e diverse azioni.

Il secondo e il terzo gruppo supportano la limitazione delle transizioni di stato. Questi due gruppi consentono di specificare una e una sola condizione che indica lo stato in cui è stato spostato un elemento di lavoro. È quindi possibile specificare una o più azioni per limitare la transizione da tale stato ad altri stati.

---

Condition

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 vengono aggiornati automaticamente per riflettere le personalizzazioni. Per questo motivo, è consigliabile creare un processo di test e un progetto di test quando si dispone di numerose personalizzazioni da eseguire per testare le personalizzazioni prima di implementarle all'organizzazione. Per altre informazioni, vedere Creare e gestire processi ereditati.

Limiti dello stato e delle regole del flusso 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, è consigliabile considerare le indicazioni seguenti per ridurre al minimo i problemi di prestazioni.

• Ridurre al minimo il numero di regole definite per un WIT. Sebbene sia possibile creare più regole per un tipo di elemento di lavoro, l'aggiunta di regole può influire negativamente sulle prestazioni quando un utente aggiunge e modifica gli elementi di lavoro. Quando gli utenti salvano gli elementi di lavoro, il sistema convalida tutte le regole associate ai campi per il tipo di elemento di lavoro. In determinate condizioni, l'espressione di convalida delle regole è troppo complessa essere valutata da SQL.
• Ridurre al minimo il numero di tipi di elementi di lavoro personalizzati definiti.

Le regole del flusso di lavoro vengono applicate durante l'aggiunta o la modifica degli elementi di lavoro tramite una delle interfacce seguenti:

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

Definire una regola

Prima di definire una regola in base agli stati del flusso di lavoro, assicurarsi di definire prima gli elementi seguenti:

• Il flusso di lavoro indica che si vuole come descritto in Personalizzare un flusso di lavoro
• Se la regola richiede una specifica di un campo personalizzato, aggiungere tale campo al tipo di elemento di lavoro come descritto in Aggiungere e gestire i campi
• Se la regola richiede una specifica di un gruppo di sicurezza per concedere o limitare le modifiche in base all'appartenenza all'utente o al gruppo, definire tale gruppo di sicurezza come descritto in Aggiungere o rimuovere utenti o gruppi, gestire i gruppi di sicurezza.

Per le nozioni di base sulla definizione delle regole, vedere Aggiungere una regola personalizzata. È necessario soddisfare i prerequisiti definiti in tale articolo.

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 garantire l'approvazione del team prima del lavoro attivo

In questo esempio, i team di sviluppo vogliono assicurarsi che nessuna storia utente venga eseguita fino all'approvazione da parte di un responsabile del team. Gli stati predefiniti del flusso di lavoro sono in uso e vengono aggiunti solo un singolo campo personalizzato, Approvato by e gruppo di sicurezza, Team Lead Group.

Stati del flusso di lavoro predefiniti

Requisiti delle regole

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

• Richiedere che il campo Approvato by venga compilato quando lo stato viene spostato da Nuovo a Attivo
• Limitare gli utenti che non appartengono al gruppo di lead team per compilare il campo Approvato da
• Deselezionare il campo Approvato per quando lo stato passa a Nuovo o Rimosso

Definizioni delle regole

I requisiti della regola vengono convertiti nelle quattro definizioni di regole seguenti.

   

---

Nome regola

Condition

Actions

---

Approvato da deselezionato quando nuovo

Quando A work item state changes to New

Poi Clear the value of Approved By

Approvato Da deselezionato quando rimosso

Quando A work item state changes to Removed

Poi Clear the value of Approved By

Approvato solo da lettura

Quando Current user is not member of group Team Leads Group

Poi Make read-only Approved By

Approvato da obbligatorio

Quando A work item state changes from New to Active

Poi 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 stato approvato

In base alla terminologia usata da un gruppo aziendale, gli stati del flusso di lavoro seguenti sono definiti per la storia utente. Gli stati ereditati nuovi, risolti e rimossi sono nascosti. Vengono invece usati stati proposti, in revisione e Cut States. Sono inoltre definiti tre stati aggiuntivi: analisi, 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 istituto regole che supportano le transizioni di stato in avanti e inverso seguenti sul tipo di elemento di lavoro di User Story.

• La proposta può essere spostata solo in Ricerca e Taglio
• La ricerca può passare solo a Design e Cut
• La progettazione può passare solo a Ricerca, Approvazione e Taglio
• Approvato può passare solo a Design, Active e Cut
• Attiva può passare solo a In Review
• In Revisione può passare solo a Attivo (lavoro aggiuntivo trovato), Chiuso o Taglia
• Chiuso 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, prendere in considerazione i casi in cui un utente sposta uno stato in errore. Si vuole che gli utenti possano recuperare correttamente.

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

• Richiedere che il campo Approvato by venga compilato quando lo stato viene spostato da Approvato a Attivo
• Consente solo agli utenti che appartengono al gruppo Approvatori autorizzati di compilare il campo Approvato da
• Deselezionare il campo Approvato per quando lo stato passa a Taglia
• Richiedere che i criteri di accettazione vengano compilati quando lo stato viene spostato su Attivo

Definizioni delle regole

Per implementare le restrizioni precedenti, l'amministratore del processo aggiunge un campo personalizzato Approvato per identità, un gruppo di sicurezza di approvazione autorizzato e le undici regole seguenti.

   

---

Nome regola

Condition

Actions

---

Stato proposto

Quando A work item state moved from Proposed

Poi 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

Poi 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

Poi 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

Poi 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

Poi 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 Verifica stato

Quando A work item state moved from In Review

Poi 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

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

Stato di taglio

Quando A work item state moved from Cut

Poi 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 dello stato approvato

Quando A work item changes from Approved to Active

Poi Make required Acceptance Criteria
E Make required Approved By

Responsabili approvazione autorizzati

Quando Current user is not a member of Authorized Approvers

Poi Make read-only Approved By

Deselezionare il campo Approvato per

Quando A work item state changes to Cut

Poi Clear the value of Approved By

---

Verificare le restrizioni di transizione dello stato

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

Per le regole definite nella tabella precedente, verranno visualizzati i menu a discesa Stato seguenti. Aprire la bacheca Kanban e controllare la possibilità di passare da uno Stato a un altro.

Proposed	Ricerca	Progettazione	Approved
Attivo	In revisione	Chiusa	Taglia

Limitare la transizione dello stato in base all'appartenenza a un utente o a un gruppo

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 degli elementi di lavoro padre in base alle assegnazioni di stato effettuate agli elementi di lavoro figlio, è possibile aggiungere un web hook e usare il codice e la configurazione forniti nel progetto GitHub Automate State Transitions .

Nota

Il progetto GitHub Automate State Transitions non è una funzionalità supportata di Azure Boards e pertanto non è supportata dal team del prodotto. Per domande, suggerimenti o problemi che si verificano quando si usano queste estensioni, generarle nella pagina del progetto GitHub.

Automatizzare la riassegnazione in base alla modifica dello stato

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

QuandoA work item state changes toRisoltoe quindiCopy the value from creato daaassegnato a.

Articoli correlati

Nota

È possibile esaminare le modifiche apportate a un processo ereditato tramite il log di controllo. Per altre informazioni, vedere Accedere, esportare e filtrare i log di controllo.

• Personalizzare un flusso di lavoro
• Aggiungere una regola personalizzata
• Memorizzazione nella cache dei moduli degli elementi di lavoro