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:

• 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 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 per supportare i requisiti di controllo
• Automatizzare la chiusura degli elementi di lavoro padre

Vedere questo articolo per informazioni su come definire le regole che si applicano quando si modifica lo stato di un flusso di lavoro.

• Informazioni sui tipi di regole del flusso di lavoro
• Limiti e procedure consigliate per lo stato del flusso di lavoro e le regole
• Impostare un valore di campo o impostare un campo di sola lettura o obbligatorio in base alla selezione 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

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

---

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.

Limiti relativi allo stato e alle 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 quando si aggiungono o 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

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 desidera come descritto in Personalizzare un flusso di lavoro
• Se la regola richiede la 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 la specifica di un gruppo di sicurezza per concedere o limitare le modifiche in base all'appartenenza a utenti o gruppi, definire tale gruppo di sicurezza come descritto in Aggiungere o rimuovere utenti o gruppi, gestire i gruppi di sicurezza.

Per informazioni 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 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 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 da e gruppo di sicurezza, Gruppo lead team.

Stati predefiniti del flusso di lavoro

Requisiti delle regole

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

• Richiedi che il campo Approvato da venga compilato quando lo stato passa da Nuovo a Attivo
• Limitare gli utenti che non appartengono al gruppo di lead del team per 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

In linea con la terminologia usata da un gruppo aziendale, 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 . Inoltre, vengono definiti tre stati aggiuntivi: 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 inverso seguenti sul tipo di elemento di lavoro Storia utente.

• Proposta può passare solo alla ricerca e al taglio
• La ricerca può passare solo a Design e Cut
• Il design può passare solo a Ricerca, Approvato e Taglio
• Approvato può passare solo a Progettazione, Attivo e Taglia
• Attivo può passare solo a In Revisione
• In Revisione può passare solo ad Attivo (lavoro aggiuntivo trovato), Chiuso o Taglia
• Closed può passare a Research, Design, Active, In Review (Consente ai casi in cui l'utente ha chiuso l'elemento di lavoro in errore)
• Cut 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 normalmente.

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

• Richiedi che il campo Approvato per venga compilato quando lo stato passa da Approvato ad Attivo
• Consentire solo agli utenti che appartengono al gruppo Responsabili approvazione autorizzati di compilare il campo Approvato da
• Deselezionare il campo Approvato da quando lo stato passa a Taglia
• Richiedi che i criteri di accettazione vengano compilati quando lo stato passa ad Attivo

Definizioni delle regole

Per implementare le restrizioni precedenti, l'amministratore del processo aggiunge un campo personalizzato Approvato per identità, un gruppo di sicurezza Responsabili approvazione autorizzati e le undici 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 il progetto aggiornato con il processo, aggiornare il browser e controllare le operazioni tramite il modulo dell'elemento di lavoro e dal browser.

Per le regole definite nella tabella precedente, verranno visualizzati i menu a discesa Stato seguenti. Aprire la scheda e controllare la possibilità di 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 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, generarli nella pagina del progetto GitHub.

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

Nota

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 dell'elemento di lavoro