Esempi di scenari di regole personalizzate

  • Articolo

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

Questo articolo fornisce esempi di definizioni di regole personalizzate. Tutte le regole personalizzate vengono definite per un tipo di elemento di lavoro. Sono disponibili esempi per i modelli di processi XML ereditati e locali.

Prima di aggiungere regole personalizzate, leggere Regole e valutazione delle regole e Aggiungere una regola a un tipo di elemento di lavoro (processo di ereditarietà).

Definire un campo obbligatorio dipendente

È possibile specificare che un campo è obbligatorio solo quando un altro campo contiene un valore specifico. Nell'esempio seguente, quando un cliente segnala un problema, il campo personalizzato Customer Reported è impostato su True e il campo Gravità diventa obbligatorio. Se il problema non viene segnalato da un cliente, non è necessario un valore per il campo Gravità .

Screenshot della regola personalizzata per rendere obbligatorio il livello di gravità quando customer REported field=true.

Cancellare il valore di un campo dipendente

Nell'esempio seguente viene illustrata la definizione di una regola personalizzata per cancellare il valore di Story Points quando viene apportata una modifica alla data di inizio.

Screenshot della regola personalizzata per cancellare il valore di Punti storia quando cambia la data di inizio.

Impostare un valore di campo dipendente

Gli esempi seguenti illustrano come eseguire il mapping dei valori del campo Dimensioni a seconda del valore selezionato per il campo personalizzato, Tee-Shirt Size campo.

L'elenco a discesa Taglia tee-shirt è costituito da quattro valori Small, Medium, Large e X-Large. Vengono definite quattro regole personalizzate per assegnare il campo Dimensioni quando il campo Dimensioni tee-shirt viene modificato in un valore specifico. Per semplificare l'utilizzo, il valore predefinito della taglia della tee-shirt è Small.

Finestra di dialogo Modifica campo per il campo Dimensioni tee-shirt

Screenshot della finestra di dialogo Modifica campo per il campo Dimensioni tee-shirt.

Regola personalizzata

Screenshot della regola personalizzata per impostare il valore size quando La dimensione della tee-shirt è impostata su Small.

Quattro regole personalizzate

Screenshot di quattro regole personalizzate per impostare il valore size quando è impostata La dimensione della maglietta.

Richiedi un valore di campo in caso di modifiche dello stato

Nell'esempio seguente viene illustrato come è possibile richiedere la specifica del campo Lavoro rimanente quando lo stato del flusso di lavoro dell'attività cambia in Attivo.

Screenshot della regola personalizzata per rendere obbligatorio il lavoro rimanente quando lo stato viene modificato in Attivo.

Cancellare il valore di un campo alla chiusura dello stato

Per automatizzare la cancellazione del campo Lavoro rimanente alla chiusura di un'attività, definire una regola personalizzata come indicato.

Screenshot della regola personalizzata su zero lavoro rimanente richiesto quando lo stato viene modificato in Chiuso.

Limitare la creazione di elementi di lavoro da un gruppo

Una regola personalizzata che limita la transizione alla categoria Stato proposto di un tipo di elemento di lavoro impedisce la creazione di elementi di lavoro di tale tipo. Applicando la regola a un gruppo specifico, si impedisce effettivamente a tale gruppo di creare elementi di lavoro di tale tipo.

La regola personalizzata seguente impedisce a un team di progetto di creare elementi di lavoro come categoria Stato proposto viene mappato allo stato Nuovo flusso di lavoro.

Screenshot della regola personalizzata per limitare la creazione di un elemento di lavoro da parte di un gruppo.

Limitare la modifica degli elementi di lavoro in base a un gruppo

Per un processo di ereditarietà, è possibile impedire agli utenti di modificare un elemento di lavoro impostando l'autorizzazione nega per un gruppo in un percorso di area. Per un processo XML locale, è possibile applicare restrizioni a ogni stato del flusso di lavoro per un gruppo che impedisce loro di salvare l'elemento di lavoro in qualsiasi stato.

Non è possibile definire una regola personalizzata che limita la modifica degli elementi di lavoro di un tipo specifico. È possibile specificare solo restrizioni in base allo stato. Se l'utente non modifica lo stato, può modificare altri campi, a meno che tutti i campi non vengano resi di sola lettura per il gruppo.

Se invece si desidera limitare la modifica di un gruppo di utenti alla selezione di elementi di lavoro di qualsiasi tipo, è possibile assegnare tali elementi di lavoro a un percorso di area. Definire un gruppo di sicurezza e quindi impostare restrizioni per la modifica degli elementi di lavoro per tale percorso area per tale gruppo, come illustrato nell'immagine seguente. Per altre informazioni, vedere Impostare le autorizzazioni e l'accesso per il rilevamento del lavoro, Creare nodi figlio e modificare gli elementi di lavoro in un percorso di area

Screenshot della finestra di dialogo Autorizzazioni per un percorso di area per limitare le modifiche degli elementi di lavoro.

Limitare le transizioni di stato

Per i processi ereditati, le transizioni di stato any-to-any vengono definite automaticamente. Ciò consente agli utenti di avanzare lo stato del flusso di lavoro da nuovo a completato, ma anche di spostarsi all'indietro nel caso sia necessario. Quando si definiscono regole personalizzate per limitare una transizione, tenere presente che se un utente commette un errore nell'aggiornamento del flusso di lavoro, potrebbe non essere in grado di correggerlo. Ad esempio, è possibile aggiornare lo stato spostando una scheda dell'elemento di lavoro in una fase successiva della scheda Kanban, ma non spostandola indietro.

Suggerimento

Prendere in considerazione la limitazione di una transizione di stato per alcuni utenti, ma non per tutti gli utenti. In questo modo, se un utente commette un errore, può chiedere a un altro membro del team di reimpostare il valore di Stato per ignorare la restrizione.

Prima di definire le regole di transizione dello stato, vedere Regole e valutazione delle regole, Regole generate automaticamente e Come vengono usati gli stati e le categorie di stato del flusso di lavoro in Backlog e Boards.

Limitare la modifica degli elementi di lavoro chiusi

A seconda dei processi aziendali, è possibile impedire agli utenti di continuare a modificare o aggiornare gli elementi di lavoro chiusi o completati. È possibile aggiungere regole ai tipi di elemento di lavoro per impedire agli utenti di ria aprire nuovamente gli elementi di lavoro chiusi.

Per il processo Ereditato, è possibile aggiungere una regola che limita la transizione di stato. Ad esempio, la regola seguente limita la transizione da chiuso agli altri due stati, New e Active.

Nota

La A work item state moved from ... condizione è disponibile per Azure DevOps Server 2020 e versioni successive.

Regola personalizzata, l'utente corrente non è membro di un gruppo, non consente le transizioni allo stato Nuovo o Attivo da Chiuso

Nota

A seconda dell'azione della regola specificata, il pulsante Salva nel modulo dell'elemento di lavoro può essere disabilitato oppure viene visualizzato un messaggio di errore quando un utente con restrizioni tenta di modificare l'elemento di lavoro.

Nascondere o limitare la modifica di un campo in base a un utente o a un gruppo

Quando si seleziona o Current user is a member of group...Current user is not a member of group..., è possibile nascondere un campo, impostare un campo di sola lettura o impostare un campo obbligatorio.

Ad esempio, la condizione seguente indica che il campo Giustificazione è nascosto per i membri che non appartengono al gruppo Fabrikam Fiber\Voice.

Regola personalizzata, l'utente corrente non è membro di un gruppo, Nascondi campo Giustificazione

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.

Limitare la modifica dei campi selezionati in base a un utente o a un gruppo

È possibile personalizzare i tipi di elemento di lavoro per limitare chi può modificare un campo specifico per un tipo di elemento di lavoro.

Nota

Per Azure DevOps Server 2019 e versioni precedenti, è possibile limitare solo la modifica degli elementi di lavoro in base a un utente o a un gruppo con il modello di processo XML locale.

Usando una delle due condizioni seguenti, è possibile selezionare i campi necessari per un utente di un gruppo di sicurezza o che non sono membri di un gruppo di sicurezza.

  • current user is a member of a group...
  • current user is not a member of a group...

Suggerimento

Per evitare problemi di valutazione delle regole che possono verificarsi, specificare i gruppi di sicurezza di Azure DevOps e non Microsoft Entra ID o i gruppi di sicurezza di Active Directory. Per altre informazioni, vedere Regole predefinite e motore regole.

Ad esempio, è possibile impostare i campi Titolo o Stato Di sola lettura per gli utenti o i gruppi selezionati.

Il campo Priorità, ad esempio, per il tipo di elemento di lavoro User Story diventa di sola lettura per i membri del gruppo Fabrikam Fiber\Voice. Quando un utente di questo gruppo apre una storia utente, non è possibile modificare il valore nel campo Priorità.

Regola personalizzata, l'utente corrente non è membro di un gruppo, imposta il campo Priorità di sola lettura