Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Questo articolo fornisce esempi di definizioni di regole personalizzate. Definire tutte le regole personalizzate per un tipo di elemento di lavoro. L'articolo fornisce esempi per i modelli di processo XML ereditati e locali.
Prima di aggiungere regole personalizzate, vedere 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, impostare il campo Customer Reported su True e il campo Severity diventa obbligatorio. Se il problema non viene segnalato da un cliente, non è necessario un valore per il campo Gravità .
Cancellare il valore di un campo dipendente
Nell'esempio seguente viene illustrato come definire una regola personalizzata per cancellare il valore di Story Points quando si modifica la data di inizio.
Impostare un valore di campo dipendente
Negli esempi seguenti viene illustrato come eseguire il mapping dei valori del campo Dimensioni a seconda del valore selezionato per il campo personalizzato Tee-Shirt Dimensioni .
L'elenco di selezione Tee-Shirt Dimensioni è costituito da quattro valori: Small, Medium, Large e X-Large. Quattro regole personalizzate assegnano il campo Dimensioni quando si modifica il campo Tee-Shirt Dimensione in un valore specifico. Per semplificare l'utilizzo, il valore predefinito della taglia della tee-shirt è Small.
Finestra di dialogo per modificare il campo Taglia T-shirt
Regola personalizzata
Quattro regole personalizzate
Richiedere 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.
Cancellare il valore di un campo quando lo stato è Chiuso
Per automatizzare la cancellazione del campo Lavoro rimanente quando si chiude un'attività, definire una regola personalizzata come indicato.
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, non è possibile che tale gruppo crei elementi di lavoro di tale tipo.
La seguente regola personalizzata impedisce a un team di progetto di creare elementi di lavoro poiché la categoria di stato Proposto è mappata allo stato del flusso di lavoro Nuovo.
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à, impedire agli utenti di modificare un elemento di lavoro impostando l'autorizzazione di negazione per un gruppo nel percorso dell'area. Per un processo XML locale, 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 siano di sola lettura per il gruppo.
Per impedire a un gruppo di utenti di modificare gli elementi di lavoro selezionati di qualsiasi tipo, 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 monitoraggio del lavoro, Creare nodi figlio e modificare gli elementi di lavoro in un percorso di area.
Limitare le transizioni di stato
Per i processi ereditati, le transizioni di stato da un qualsiasi punto a un qualsiasi altro sono definite automaticamente. Questa definizione del flusso di lavoro consente agli utenti di avanzare lo stato del flusso di lavoro da nuovo a completato, ma anche di spostarsi all'indietro nel caso in cui sia necessaria l'azione. 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 nel quadro, senza riportarla 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 le transizioni di stato. Ad esempio, la regola seguente limita la transizione da chiuso agli altri due stati, Nuovo e Attivo.
Nota
La A work item state moved from ... condizione è disponibile per Azure DevOps Server 2020 e versioni successive.
Nota
A seconda dell'azione della regola specificata, il pulsante Salva nel modulo dell'elemento di lavoro è disabilitato o 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 la Current user is a member of group... condizione o 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 nasconde il campo Giustificazione per i membri che non appartengono al gruppo Fabrikam Fiber\Voice.
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 ti trovi limitato ad aggiornare un elemento di lavoro, potresti aver incontrato una di queste regole. Se ritieni di aver riscontrato un problema che non riguarda te, consulta Problemi di memorizzazione nella cache di IndexDB nel modulo dell'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.
È possibile usare una delle due condizioni seguenti per selezionare i campi necessari per un utente di un gruppo di sicurezza o per gli utenti 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, specificare i gruppi di sicurezza di Azure DevOps anziché l'ID Microsoft Entra 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.
Ad esempio, il campo Priorità, 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 può modificare il valore nel campo Priorità.
