Regole e valutazione delle regole

Articolo
03/25/2024

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

Le regole consentono di impostare o limitare le assegnazioni di valori a un campo dell'elemento di lavoro. Esistono due tipi principali di regole, ovvero regole generate automaticamente e regole personalizzate definite per un processo o un progetto. Le regole generate automaticamente riducono la necessità di aggiungere regole personalizzate per le aree che devono funzionare in modalità standard.

È possibile definire regole personalizzate per supportare i casi d'uso aziendali specifici. A seconda del tipo di dati di un campo, è possibile impostare varie restrizioni sui dati che possono essere immessi in tale campo. È possibile specificare i valori per un elenco di selezione (menu a discesa), impostare valori predefiniti, cancellare voci o limitare le modifiche. Con le regole condizionali, è possibile applicare le regole a un campo in base alle dipendenze tra i valori di campi diversi. È anche possibile limitare gli utenti che possono modificare un campo o impostare solo un gruppo come ambito di una regola.

Leggere questo articolo per comprendere quanto segue:

Modalità di applicazione delle regole generate automaticamente dal sistema
Restrizioni applicate alla definizione di regole personalizzate nei campi di sistema
I diversi tipi di regole personalizzate che è possibile applicare
Come vengono valutate le regole
Differenza tra le regole definite per un processo di ereditarietà rispetto a un processo XML locale
Perché è consigliabile ridurre al minimo il numero di regole personalizzate definite

Prima di definire regole personalizzate, leggere Configurare e personalizzare Azure Boards per comprendere in modo più ampio come personalizzare Azure Boards per soddisfare le esigenze aziendali.

Suggerimento

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.

Regole generate automaticamente

Le regole generate automaticamente riducono la necessità di aggiungere regole personalizzate per le aree che devono funzionare in modalità standard.

Regole di transizione dello stato

I processi ereditati generano l'intero set di regole di transizione di stato any-to-any in modo dinamico per ogni tipo di elemento di lavoro personalizzato e lo stato personalizzato aggiunto a un flusso di lavoro. Una transizione da qualsiasi stato a qualsiasi stato è valida.

Per i processi XML locali, è necessario specificare le transizioni valide all'interno della WORKFLOW sezione della definizione del tipo di elemento di lavoro.

Transizioni di stato e regole di campo Per/Data

I campi Per/Data corrispondono a Created By/Date, Activated By/Date, Resolved By/Date e Closed By/Date.

Per i processi ereditati, questi campi vengono impostati o cancellati automaticamente quando si esegue la transizione di un elemento di lavoro da uno stato a un altro. I campi Changed By/Date non sono inclusi perché vengono aggiornati con ogni salvataggio dell'elemento di lavoro e non sono correlati alle transizioni di stato.

Le regole e i comportamenti predefiniti che regolano questi campi includono:

Lo stato Chiuso è sempre contenuto nella categoria Stato completato .
La categoria Stato completato non è configurabile ed è associata a uno e a un solo stato.
Questo stato Closed è sempre Chiuso per i processi Agile e CMMI e sempre Fatto per i processi Scrum e Basic.
La generazione automatica di queste regole è interessata dalle impostazioni locali perché la condizione della regola contiene il nome dello stato, localizzato. Il sistema genera regole diverse per impostazioni locali diverse.
Le regole generate automaticamente per questi campi vengono specificate solo per i tipi di elemento di lavoro che includono questi campi. È possibile che un tipo di elemento di lavoro non includa uno o più di questi campi.
Queste regole sono necessarie quando un tipo di elemento di lavoro ha stati personalizzati o il tipo di elemento di lavoro è un tipo di elemento di lavoro personalizzato.
Queste regole si applicano solo ai processi ereditati; non vengono mai generati per i processi XML ospitati o XML locali.

Gli stati del flusso di lavoro sono associati alle categorie di stato per supportare il flusso di lavoro nelle bacheche. Per altre informazioni, vedere Come vengono usati gli stati del flusso di lavoro e le categorie di stato nei backlog e nelle bacheche.

Regole dei campi Data modifica stato

Queste regole sono tecnicamente molto più semplici rispetto alle regole di data chiusa/chiuso perché non dipendono da uno stato specifico. Per qualsiasi tipo di elemento di lavoro, le stesse regole funzioneranno sempre. Devono essere generati automaticamente perché alcuni tipi di elemento di lavoro OOB non contengono il campo Data modifica stato, quindi quando l'utente aggiunge questo campo a un tipo di elemento di lavoro personalizzato, queste regole devono anche essere generate automaticamente. Gli stessi principi per le regole di data chiusa/chiusa si applicano anche qui.

Regole personalizzate

Tutte le regole personalizzate sono facoltative. Per un processo ereditato, specificare una regola costituita da una condizione più un'azione. Per un processo XML locale, è necessario specificare regole per un campo o all'interno del flusso di lavoro.

Non esiste un mapping uno-a-uno tra i due processi. In alcuni casi, la regola dell'elemento XML viene definita all'interno della finestra di dialogo Modifica campo per il processo ereditato e non come regola. Altri elementi XML, ad esempio FROZEN, MATCH, NOTSAMEAS, non sono supportati nel processo ereditato.

Notare quanto segue:

Le regole vengono sempre applicate, non solo quando si interagisce con il modulo, ma anche quando si interagisce con altri strumenti. Ad esempio, l'impostazione di un campo come di sola lettura non applica solo la regola nel modulo dell'elemento di lavoro, ma anche tramite l'API e il componente aggiuntivo Azure DevOps Server di Excel.
Le voci di processo ereditate specificano condizioni e azioni per creare una regola completa. Gli elementi XML non fanno tali distinzioni.
Le regole dei campi non supportano l'assegnazione di valori che sono la somma di altri due campi o l'esecuzione di calcoli matematici diversi. Tuttavia, è possibile trovare una soluzione adatta alle proprie esigenze tramite l'estensione TFS Aggregator (Servizio Web) Marketplace. Vedere anche Rollup del lavoro e altri campi.
È possibile trovare soluzioni aggiuntive per applicare regole personalizzate ai campi usando estensioni del Marketplace, ad esempio l'estensione libreria di controlli modulo elementi di lavoro.

Per un processo ereditato, ogni regola è costituita da due parti: Condizioni e Azioni. Le condizioni definiscono le circostanze che devono essere soddisfatte affinché la regola venga applicata. Le azioni definiscono le operazioni da eseguire. Per la maggior parte delle regole, è possibile specificare un massimo di due condizioni e 10 azioni per regola. Tutte le regole personalizzate richiedono che tutte le condizioni vengano soddisfatte per l'esecuzione.

Ad esempio, è possibile impostare un campo obbligatorio in base al valore assegnato allo stato e a un altro campo. Ad esempio:

   (Condition) When a work item State isAttivo
   (Condition) And when the value of = Area valoreAzienda
   (Action) Then make requiredPunti storia

Nota

Attualmente, è supportata una sola condizione per le regole di transizione stato. Se si applicano regole basate su Stato, vedere Applicare regole agli stati del flusso di lavoro.

La tabella seguente riepiloga le azioni disponibili con le condizioni selezionate.

Condizione

Azioni supportate

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

Condizioni, viene creato un elemento di lavoro

Azioni, viene creato un elemento di lavoro

Limitare una transizione in base allo stato

Condizione, elemento di lavoro spostato

Azioni, limitare una transazione in base allo stato.

Nascondere il campo o rendere il campo di sola lettura o obbligatorio in base all'appartenenza a stato e utente o gruppo

Condizione, appartenenza al gruppo di utenti

Azioni, limitare una transazione in base allo stato e all'appartenenza.

In base all'appartenenza a utenti o gruppi, impostare l'attributo del campo o limitare una transizione di stato

Condizione, appartenenza al gruppo di utenti

Azioni, limitare una transazione in base allo stato e all'appartenenza.

Il processo XML locale definisce le regole utilizzando elementi XML. Tutti questi elementi della regola possono essere definiti all'interno della FIELD definizione di una definizione del tipo di elemento di lavoro. Inoltre, ad eccezione dell'elemento HELPTEXT , è possibile specificare queste regole da influire durante una transizione del flusso di lavoro o come elementi figlio all'interno di un FIELD elemento (flusso di lavoro globale).

Regole dei campi degli elementi XML di rilevamento degli elementi di lavoro

Nota

L'elemento VALIDUSER non è supportato per TFS 2018 e versioni successive.

Dove applicare una regola di campo

Quando si desidera che una regola venga applicata a un campo per tutta la durata dell'elemento di lavoro, specificarla all'interno della FIELD sezione . Ad esempio, un campo obbligatorio per un bug nuovo e attivo rimane obbligatorio fino alla chiusura del bug. In caso contrario, se si desidera applicarlo in base a una modifica in Stato, Motivo o transizione, specificarlo all'interno della WORKFLOW sezione .

I campi State (System.State) e Reason (System.Reason) sono definiti all'interno della WORKFLOW sezione . È possibile specificare la maggior parte delle regole di campo da applicare a un campo durante una modifica dello stato, la selezione di un motivo o per una transizione specifica. Per altre informazioni, vedere Modificare il flusso di lavoro per un tipo di elemento di lavoro.

In caso contrario, specificare una regola da valutare solo durante una modifica dello stato. Queste regole vengono definite all'interno della WORKFLOW sezione STATEnegli elementi , REASONo TRANSITION . Tutte le regole, ad eccezione di HELPTEXT, possono essere applicate all'interno di un FIELD elemento (Workflow).

Le regole dei campi sono additive. Ciò significa che è possibile specificare quattro set di regole per lo stesso campo che verranno tutti valutati dal motore regole.

Le regole specifiche del tipo di elemento di lavoro si applicano indipendentemente dalla posizione di un elemento di lavoro nel modello di stato. Ad esempio, una <REQUIRED \> regola esegue il controllo seguente:

"MyField Value" != NULL
Le regole specifiche dello stato hanno come ambito un'istanza dell'elemento di lavoro quando si trova in un determinato stato. Quando la condizione seguente è true, viene applicata una regola specifica dello stato:

State field value == "MyState" && "MyField Value" != NULL
Le regole specifiche della transizione specificate per una transizione specifica hanno come ambito un elemento di lavoro che sta eseguendo una determinata transizione. Queste regole vengono applicate quando vengono soddisfatte le condizioni seguenti:

State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL
Le regole specifiche del motivo specificate per un motivo specifico hanno come ambito un motivo specifico per una particolare transizione. Vengono elaborati quando vengono soddisfatte le condizioni seguenti:

Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

L'esempio seguente limita la modifica del campo di gravità del cliente quando l'elemento di lavoro si trova nello stato Attivo.

<STATE name="Active">
      <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
      </FIELDS>
</STATE>

Cosa accade se sono definite troppe regole

Viene definita una singola espressione SQL per ogni progetto per convalidare gli elementi di lavoro ogni volta che vengono creati o aggiornati. Questa espressione aumenta con il numero di regole specificate per tutti i tipi di elemento di lavoro definiti per il progetto. Ogni qualificatore comportamentale specificato per un campo comporta un aumento del numero di sottoespressione. Regole annidate, regole che si applicano solo a una transizione o condizionale sul valore di un altro campo, determinano l'aggiunta di più condizioni a un'istruzione IF . Quando l'espressione raggiunge una determinata dimensione o complessità, SQL non può valutarlo più e genera un errore. La rimozione di alcune connessioni WIT o l'eliminazione di alcune regole può risolvere l'errore.

È possibile specificare i valori per un elenco di selezione (menu a discesa), impostare valori predefiniti, cancellare voci o limitare le modifiche. Con le regole condizionali, è possibile applicare le regole a un campo in base alle dipendenze tra i valori di campi diversi. È anche possibile limitare gli utenti che possono modificare un campo o impostare solo un gruppo come ambito di una regola.

Le regole degli elementi di lavoro non esistono come una singola raccolta. Le regole vengono effettivamente generate e unite dinamicamente da origini dati diverse. La logica di unione è una semplice, consolidare regole identiche, ma non tagliare regole in conflitto.

Ignora regole

In generale, tutti gli elementi di lavoro vengono convalidati dal motore delle regole quando gli utenti modificano l'elemento di lavoro. Tuttavia, per supportare determinati scenari, agli utenti a cui è stata assegnata l'autorizzazione Bypass per gli aggiornamenti degli elementi di lavoro a livello di progetto può salvare gli elementi di lavoro senza che vengano valutate regole.

Le regole possono essere ignorate in uno dei due modi. Il primo consiste nell'usare l'API REST Elementi di lavoro - aggiornare l'API REST e impostare il bypassRules parametro su true. Il secondo avviee tramite il modello a oggetti client, inizializzando in modalità bypassrules (inizializzare WorkItemStore con WorkItemStoreFlags.BypassRules).

Campi di sistema e regole personalizzate

I campi di sistema hanno System.Nomi di riferimento, ad esempio System.Title e System.State.

I campi di sistema seguenti devono avere un valore: ID area, Data modificata, Data creazione, Creato da, Stato e Motivo.

Il motore regole limita l'impostazione di condizioni o azioni ai campi di sistema, ad eccezione dei seguenti:

È possibile impostare i campi State e Reason di sola lettura.
È possibile applicare la maggior parte delle regole ai campi Titolo, Assegnato a, Descrizione e Modificato da .

Se non viene visualizzato un campo elencato nel menu a discesa dell'interfaccia utente della regola per il processo di ereditarietà, ecco perché. Ad esempio, se si tenta di impostare percorso area (System.AreaPath) di sola lettura in base a una condizione, il campo Percorso area non è disponibile per la selezione. Anche se è possibile specificare un campo di sistema, il motore delle regole potrebbe impedire il salvataggio della regola.

Regole predefinite e copiate

Le regole predefinite e di copia modificano i valori dei campi dell'elemento di lavoro. Definiscono il comportamento e i vincoli di runtime, ad esempio la specifica di valori predefiniti, la cancellazione dei campi, la necessità di definire campi e altro ancora.

È possibile limitare l'applicazione di queste regole in base all'appartenenza al gruppo dell'utente corrente, come descritto in Restrizioni delle regole di appartenenza a utenti o gruppi.

Processo di ereditarietà
Processo XML locale

La maggior parte di queste azioni di regola può essere applicata con la selezione di qualsiasi condizione.

Azione del processo ereditato

Descrizione

Copy the value from...

Specifica un altro campo che contiene un valore da copiare nel campo corrente.

Clear the value of...

Cancella il campo di qualsiasi valore che contiene.

Use the current time to set the value of ...

Imposta l'ora di un campo in base all'impostazione dell'ora dell'utente corrente.

Queste regole supportano l'impostazione predefinita, la copia di valori da un campo a un altro o l'applicazione di un valore di campo in modo che corrisponda a un criterio prestabilito. Per la struttura della sintassi e gli esempi, vedere Definire un valore predefinito o copiare un valore in un campo.

Elemento XML

Utilizzo

COPY

Copia un valore specificato in un campo quando un utente crea o modifica un elemento di lavoro.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD>

DEFAULT

Specifica un valore per un campo vuoto quando un utente crea o modifica un elemento di lavoro. Se un campo ha già un valore, la DEFAULT regola viene ignorata. Le regole predefinite vengono eseguite solo se il Is valore del campo è attualmente vuoto. I valori supportati includono l'ora corrente (from = "clock"), l'utente corrente (from = "currentuser"), un valore letterale (from = "value" value = "literal") o il valore di un altro campo (from = field field = "referenceNameField").

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD

SERVERDEFAULT

Specifica l'orologio del server o l'utente corrente per definire un valore di campo.

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>

Regole vincolo

Le regole di vincolo limitano la modifica del valore di un campo. Definiscono gli stati validi per un elemento di lavoro. Ogni vincolo opera su un singolo campo. I vincoli vengono valutati nel server sul salvataggio dell'elemento di lavoro e, se viene violato un vincolo, l'operazione di salvataggio viene rifiutata.

È possibile limitare l'applicazione di queste regole in base all'appartenenza al gruppo dell'utente corrente, come descritto in Restrizioni delle regole di appartenenza a utenti o gruppi.

Processo di ereditarietà
Processo XML locale

La maggior parte di queste azioni di regola può essere applicata con la selezione di qualsiasi condizione.

Azione del processo ereditato

Descrizione

Hide the field...
Disponibile solo quando è selezionata una condizione di appartenenza a un gruppo.

Specifica di non visualizzare il campo nel modulo dell'elemento di lavoro, rimuovendo essenzialmente la possibilità per l'utente corrente di modificare il valore del campo.

Make read-only

Impedisce la modifica di un campo. È possibile applicare questa regola in determinate condizioni. Ad esempio, dopo la chiusura di un elemento di lavoro, si vuole rendere un campo di sola lettura per conservare i dati a scopo di creazione di report.
Per specificare il valore predefinito del campo è di sola lettura, specificare nella finestra di dialogo Modifica campo, scheda Opzioni .

Make required

Richiede a un utente di specificare un valore per il campo. Gli utenti non possono salvare un elemento di lavoro finché non hanno assegnato valori a tutti i campi obbligatori.
Per specificare il valore predefinito del campo, specificare nella finestra di dialogo Modifica campo, scheda Opzioni .

Elemento XML

Utilizzo

ALLOWEDVALUES

Definisce un elenco di valori consentiti per il campo. I valori consentiti sono valori disponibili per la selezione in un elenco di campi nei moduli degli elementi di lavoro e nel generatore di query. È necessario selezionare uno di questi valori.

CANNOTLOSEVALUE

Impedisce agli utenti di cancellare un campo di un valore dopo che è stato specificato un valore. Questo elemento mantiene il valore del campo corrente e non può essere cancellato o reso vuoto.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD>

FROZEN

Impedisce agli utenti di modificare il valore di un campo una volta che contiene un valore. Non appena un utente salva l'elemento di lavoro con un valore in tale campo, il valore non può più essere modificato. Non è possibile modificare un campo bloccato in un valore non vuoto dopo il commit delle modifiche. Tuttavia, è possibile cancellare manualmente il campo, salvare l'elemento di lavoro e quindi specificare un valore diverso.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD>

EMPTY

Cancella il campo di qualsiasi valore contenuto e quindi imposta il campo di sola lettura quando un utente salva l'elemento di lavoro. Non è consigliabile usare EMPTY con READONLY.
EMPTY viene utilizzato principalmente durante la transizione dello stato per cancellare i campi che si applicano allo stato a cui viene eseguita la transizione dell'elemento.

<FIELD refname="MyCorp.SubStatus" />  
   <WHEN field="MyCorp.Status" value="Approve" >  
     <EMPTY />
   </WHEN>  
</FIELD>

MATCH

Forza le voci eseguite in un campo Stringa in modo che siano conformi a un criterio di caratteri o numeri specificato. Se si definiscono più MATCH elementi, il valore viene considerato valido se corrisponde a uno dei modelli specificati. Se almeno un elemento ha esito positivo, il campo ha un valore valido.

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

Impedisce che a un campo venga assegnato lo stesso valore assegnato a un altro campo.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD>

PROHIBITEDVALUES

Definisce un elenco di valori non consentiti per il campo. Se più ALLOWEDVALUES regole e/o PROHIBITEDVALUES si applicano a un determinato campo, l'elenco completo di valori validi è l'intersezione di tutti gli elenchi di valori consentiti, o tutto, se non sono presenti elenchi di valori consentiti, ovvero la differenza impostata, l'unione di tutti gli elenchi di valori non consentiti.

READONLY

Impedisce la modifica di un campo. È possibile applicare questa regola in determinate condizioni. Ad esempio, dopo la chiusura di un elemento di lavoro, si vuole rendere un campo di sola lettura per conservare i dati a scopo di creazione di report.
Non usare READONLY con l'elemento EMPTY perché EMPTY rende anche un campo di sola lettura. La combinazione di questi elementi può produrre risultati incoerenti.
Inoltre, è possibile visualizzare un campo come di sola lettura dal modulo dell'elemento di lavoro usando l'attributo Control element ReadOnly . Il campo può essere scritto in da altri client, ma non tramite il modulo dell'elemento di lavoro.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD>

REQUIRED

Richiede a un utente di specificare un valore per il campo. Gli utenti non possono salvare un elemento di lavoro finché non hanno assegnato valori a tutti i campi obbligatori.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD>

Elenchi di selezione

Gli elenchi di selezione definiscono i valori che un utente può o non può scegliere per un campo String o Integer. I valori definiti in un elenco di selezione vengono visualizzati in un modulo dell'elemento di lavoro e nell'editor di query.

Processo di ereditarietà
Processo XML locale

Per un processo ereditato, gli elenchi di selezione vengono definiti tramite la finestra di dialogo Modifica campo.

Finestra di dialogo Modifica campo

Descrizione

Scheda Definizione per un campo elenco a discesa

Selezionare la casella di controllo Consenti agli utenti di immettere i propri valori nella scheda Opzioni per consentire agli utenti di specificare le proprie voci

Definisce un elenco di valori suggeriti per il campo. I valori suggeriti sono valori disponibili per la selezione in un elenco di campi nei moduli degli elementi di lavoro e nel generatore di query. È possibile immettere altri valori anche a quelli nell'elenco.

Gli elenchi di selezione vengono definiti usando gli elementi XML elencati nella tabella seguente. Per la struttura della sintassi e gli esempi, vedere Definire elenchi di selezione.

È possibile combinare elenchi ed espandere o elenchi di contratti. Inoltre, è possibile limitare l'applicazione di queste regole in base all'appartenenza al gruppo dell'utente corrente, come descritto in Restrizioni delle regole di appartenenza a utenti o gruppi.

Elemento XML

Descrizione

ALLOWEDVALUES

ALLOWEXISTINGVALUE

Definisce il campo per consentire i valori esistenti. Questo elemento consente l'utilizzo dei valori di campo già esistenti, anche se non sono validi. Tutti i nuovi valori di campo devono essere validi.

PROHIBITEDVALUES

Definisce un elenco di valori non consentiti per il campo.

SUGGESTEDVALUES

Campi di identità ed errori di convalida

Per evitare errori di convalida che altrimenti si verificano quando i membri lasciano il team e non sono più registrati come collaboratori del progetto, includere l'elemento ALLOWEXISTINGVALUE per il campo Assigned To .

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
      <HELPTEXT>The user who is working on this work item</HELPTEXT>
      <ALLOWEXISTINGVALUE />
      <VALIDUSER />
      <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
      <LISTITEM value="Active" />
      <LISTITEM value="[project]\Contributors" />
      </ALLOWEDVALUES>
      <DEFAULT from="field" field="System.CreatedBy" />
</FIELD>

Valori o modifiche dei campi condizionali

Le regole condizionali specificano un'azione in base al valore di un campo uguale o meno a un valore specifico oppure se una modifica è stata o non è stata apportata al valore di un campo specifico. In generale, le regole condizionali vengono applicate prima rispetto alle regole non condizionali. Quando più regole condizionali restituiscono true, l'ordine di esecuzione è: When, WhenNot, WhenChanged, WhenNotChanged.

Processo di ereditarietà
Processo XML locale

È possibile specificare più regole condizionali per campo. Tuttavia, è possibile specificare solo un singolo campo di guida per ogni regola condizionale.

Condizione ereditata

Descrizione

The value of ... (equals) [Quando]

Specifica una o più regole da applicare al campo corrente quando un altro campo ha un valore specifico.

A change was made to the value of ... [WhenChanged]

Applica una o più regole al campo corrente quando viene modificato il valore di un campo specifico.

The value of ... (not equals) [WhenNot]

Applica una o più regole al campo corrente quando un altro campo non ha un valore specifico.

No change was made to the value of ... [WhenNotChanged]

Applica una o più regole al campo corrente quando il valore di un campo specifico non viene modificato.

Azione ereditata

Descrizione

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Specifica l'azione da eseguire su un campo specifico.

Gli elementi XML seguenti vengono utilizzati per impostare le condizioni per quando vengono valutate altre regole. È possibile specificare più regole condizionali per campo. Tuttavia, è possibile specificare solo un singolo campo di guida per ogni regola condizionale. Non è possibile annidare le regole condizionali. Le azioni supportate per ogni modello di processo includono quelle elencate nella tabella seguente.

Per la struttura della sintassi e gli esempi, vedere Assegnare valori e regole basati su condizionale. È possibile limitare l'applicazione di queste regole in base all'appartenenza al gruppo dell'utente corrente, come descritto in Restrizioni delle regole di appartenenza a utenti o gruppi.

Elemento XML

Utilizzo

WHEN

Specifica una o più regole da applicare al campo corrente quando un altro campo ha un valore specifico. L'elemento padre definisce il campo corrente.
Quando il campo specificato ha il valore specificato, le regole in questo elemento vengono applicate al campo corrente.

WHENCHANGED

Specifica una condizione in base alla quale applicare una o più regole al campo corrente. Le regole si applicano al campo corrente quando il valore di un altro campo viene modificato in una revisione in un elemento di lavoro. L'elemento padre definisce il campo corrente.

WHENNOT

Specifica una condizione in base alla quale applicare una o più regole al campo corrente. Le regole si applicano al campo corrente quando cambia il valore di un altro campo. L'elemento padre definisce il campo corrente.
Quando il campo specificato non contiene il valore specificato, le regole in questo elemento vengono applicate al campo corrente.

WHENNOTCHANGED

Specifica una condizione in base alla quale applicare una o più regole al campo corrente. Le regole si applicano al campo corrente quando il valore di un altro campo non viene modificato in una revisione in un elemento di lavoro. L'elemento padre definisce il campo corrente.

Restrizioni relative alle regole di appartenenza a utenti o gruppi

È possibile limitare l'applicazione di una regola in base all'appartenenza dell'utente corrente. È consigliabile definire l'ambito della regola in un gruppo di sicurezza di Azure DevOps e non in un singolo utente, anche se è possibile specificare quest'ultimo. Per impostare l'ambito della regola su più gruppi, è necessario creare un gruppo di Azure DevOps padre che includa il set di gruppi da usare.

Implementazione del processo

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.

Processo di ereditarietà
Processo XML locale

Come indicato nella tabella seguente, per limitare una regola in base all'appartenenza dell'utente corrente, specificare una delle due condizioni per un processo ereditato. Queste regole sono attive per Azure DevOps 2020 e versioni successive.

Si applica a

Regola

Condizione

Current user is a member of group ...
Current user is not member of group ...

Azione

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

Per limitare una regola in base all'appartenenza dell'utente corrente, è necessario specificare gli for attributi o not nell'elemento della regola. Specificare l'ambito della regola. Per impostare l'ambito della regola su più gruppi, è necessario creare un gruppo di Azure DevOps padre che includa il set di gruppi da usare.

Scenario

Utilizzo

Impostare un campo obbligatorio solo per un gruppo specificato

Utilizzare for per applicare una regola a un gruppo. In questo esempio è necessario che qualsiasi utente del gruppo Junior Analyst completi il campo Secondo responsabile approvazione.

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

Limitare la modifica di un campo a un gruppo di utenti

Usare not per escludere un gruppo da una regola. In questo esempio viene definito il campo Descrizione valutazione come di sola lettura per tutti gli utenti, ad eccezione di quelli del gruppo Comitato di valutazione.

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

Impostare un campo obbligatorio per alcuni utenti e non per altri utenti

Usare una combinazione di for e not per applicare contemporaneamente una regola ad alcuni e non ad altri. Questo esempio definisce gravità come campo obbligatorio per gli utenti nel gruppo Membri progetto, ma non per quelli nel gruppo Project Admins. Se un utente si trova in entrambi i gruppi, l'istruzione for verrà applicata e il campo sarà obbligatorio.

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

Usare i token per fare riferimento a utenti o gruppi

I campi Identity o People-Picker possono accettare valori che fanno riferimento sia agli utenti che ai gruppi. Quando si limita una regola a un gruppo, si indica il dominio o l'ambito del gruppo. Per alcuni valori, è possibile usare i token.

Processo di ereditarietà
Processo XML locale

Di seguito sono riportati alcuni esempi di token:

[ProjectName], ad esempio [Fabrikam], [FabrikamFiber], [MyProject]
[OrganizationName], ad esempio [fabrikam], [myorganization]
[CollectionName], ad esempio [fabrikam], [myorganization]

Per informazioni sugli ambiti disponibili per il progetto o l'organizzazione, passare alla pagina Impostazioni>progetto Gruppi di autorizzazioni>o Gruppi autorizzazioni> impostazioni>organizzazione, è possibile filtrare l'elenco in base alle esigenze. Ad esempio, l'immagine seguente mostra le prime quattro voci di un elenco filtrato basato su Azure DevOps. Per altre informazioni, vedere Modificare le autorizzazioni a livello di progetto o Modificare le autorizzazioni a livello di raccolta del progetto.

Screenshot dell'elenco dei gruppi di autorizzazioni filtrati.

Di seguito sono riportati alcuni esempi di token:

[Project], ad esempio [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approveers The [Project] token specifica un gruppo definito per un progetto. Può corrispondere a un team, a un gruppo di sicurezza predefinito o personalizzato o a un gruppo di Active Directory aggiunto al progetto.
[GLOBAL], per fare riferimento a un gruppo con ambito raccolta, ad esempio [GLOBAL]\Project Collection Administrators Usa [GLOBAL] per fare riferimento a un gruppo di sicurezza con ambito raccolta, ad esempio il gruppo Amministratori raccolta progetti o un gruppo di Windows aggiunto a una raccolta. Ad esempio:
```
<FIELD name="Title">
    <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
</FIELD>
```
[Team Foundation] per fare riferimento a un gruppo con ambito server, ad esempio [Team Foundation]\Team Foundation Administrators Usa [Team Foundation] per fare riferimento a un gruppo con ambito server, ad esempio un gruppo predefinito o un gruppo di Windows aggiunto a un gruppo a livello di server. Ad esempio:
```
<FIELD name="Title">
    <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
</FIELD>
```
[DomainName] per fare riferimento a un gruppo con ambito server, ad esempio [Team Foundation]\Team Foundation Administrators Nome account qualificato per il dominio, ad esempio quello illustrato nell'esempio seguente, può essere usato per fare riferimento a un utente o a un gruppo di dominio. Alcune regole supportano solo i gruppi e non supportano il riferimento agli utenti di dominio.
```
<LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
```

Nota

[Project], [GLOBAL], e [Team Foundation] vengono usati così come sono. Non sostituirli con il nome del progetto, della raccolta o del server.

Per informazioni sugli ambiti disponibili per il progetto o la raccolta, passare alla pagina Gruppi di autorizzazioni> Impostazioni progetto>o Gruppi di autorizzazioni> impostazioni>raccolta. Filtrare l'elenco in base alle esigenze. Ad esempio, l'immagine seguente mostra le prime quattro voci di un elenco filtrato basato su Azure DevOps. Per altre informazioni, vedere Modificare le autorizzazioni a livello di progetto o Modificare le autorizzazioni a livello di raccolta del progetto.

Screenshot dell'elenco dei gruppi di autorizzazioni filtrati.

Tutti gli utenti e i gruppi devono essere qualificati da uno di questi token. Ad esempio, il codice XML seguente non è valido perché non qualifica il gruppo specificato con un token valido.

<FIELD name="Title">
    <READONLY for="Dev Team"/>
</FIELD>

Per altre informazioni sui gruppi di sicurezza predefiniti, vedere Autorizzazioni e gruppi

Valutazione delle regole

Le regole che specificano una condizione in base all'appartenenza utente o gruppo dell'utente che modifica un elemento di lavoro vengono valutate in uno dei due modi. Quando la regola viene valutata, l'applicazione deve determinare se la regola viene applicata all'utente corrente controllando se l'utente è o non è membro del gruppo specificato.

Quando si modifica l'elemento di lavoro dal portale Web, dall'API REST o dal comando di Azure Boards , viene effettuata una richiesta all'ID Microsoft Entra o Active Directory. Non si verificano problemi per questa operazione.
Quando si modifica l'elemento di lavoro da Visual Studio, Excel o da un altro strumento personalizzato usando il modello a oggetti client WIT, la richiesta di valutare l'appartenenza si basa su una cache client. La cache client non è in grado di conoscere i gruppi di Active Directory.

Nota

Visual Studio 2019 Team Explorer per i progetti che usano GIT è stato riscritto per usare le API REST.

Per evitare problemi con gli utenti che aggiornano gli elementi di lavoro da diversi client, specificare i gruppi di sicurezza di Azure DevOps anziché i gruppi di Active Directory. È possibile creare facilmente un gruppo di sicurezza di Azure DevOps per corrispondere a un gruppo di Active Directory. Per informazioni su come, vedere Aggiungere o rimuovere utenti o gruppi, gestire i gruppi di sicurezza.

Nota

WIT Client OM è deprecato. A partire dal 1° gennaio 2020, non è più supportato quando si lavora con Azure DevOps Services e Azure DevOps Server 2020.

Ordine in cui vengono valutate le regole

Le regole vengono in genere elaborate nella sequenza in cui sono elencate. Tuttavia, la sequenza completa per la valutazione di tutte le regole non è completamente deterministica.

Questa sezione descrive il comportamento previsto e le interazioni quando si applicano regole condizionali, copia e predefinite.

Processo di ereditarietà
Processo XML locale

I passaggi seguenti illustrano, nella sequenza corretta, le interazioni eseguite da Azure DevOps e dall'utente di un modulo dell'elemento di lavoro. Solo i passaggi 1, 8 e 13 vengono eseguiti dall'utente.

Da un client Azure DevOps, ad esempio il portale Web o Visual Studio Team Explorer, un utente crea un nuovo elemento di lavoro o modifica un elemento di lavoro esistente.
Compilare le impostazioni predefinite del campo. Per tutti i campi, applicare tutte le impostazioni predefinite assegnate al campo che non fanno parte di una clausola condizionale.
Copiare o impostare i valori dei campi. Per tutti i campi, applicare le regole per copiare un valore o impostare il valore di un campo che non fanno parte di una clausola condizionale.
Per tutti i campi con una regola condizionale corrispondente, applicare regole per impostare o copiare un valore di campo.
Per tutti i campi con una regola condizionale When Not corrispondente, applicare regole per impostare o copiare un valore di campo.

Il sistema elabora sempre Quando le regole prima di Quando non vengono regolate.
Per tutti i campi con i relativi valori modificati dal passaggio 1 e che contengono regole quando sono state modificate , applicare regole per impostare o copiare un valore di campo.
Consentire all'utente di iniziare a modificare.
L'utente modifica un valore di campo e quindi sposta lo stato attivo dal campo.
Elaborare le regole When per quel campo che corrispondono al nuovo valore.
Elabora le regole When Not per quel campo che corrispondono al nuovo valore.
Elaborare le regole When Changed per quel campo che corrispondono al nuovo valore.
Restituire la possibilità di modifica all'utente.
L'utente salva le modifiche all'archivio dati.
Per tutti i campi, applicare tutte le Use the current time to set the value of ... azioni definite per il campo direttamente o indirettamente in una regola condizionale.

Le regole vengono in genere elaborate nella sequenza in cui sono elencate. Tuttavia, quando si usano gli elementi WHEN, DEFAULT e COPY , possono essere applicati comportamenti aggiuntivi. I passaggi seguenti illustrano, nella sequenza corretta, le interazioni eseguite da Azure DevOps e dall'utente di un modulo dell'elemento di lavoro. Solo i passaggi 1, 8 e 13 vengono eseguiti dall'utente.

Da un client Azure DevOps, ad esempio il portale Web o Visual Studio Team Explorer, un utente crea un nuovo elemento di lavoro o modifica un elemento di lavoro esistente.
Compilare le impostazioni predefinite del campo. Per tutti i campi, applicare tutte le regole DEFAULT specificate all'esterno o alle regole WHEN .
Copiare i valori dei campi. Per tutti i campi, utilizzare tutte le regole COPY esterne alle clausole WHEN .
Per tutti i campi con una regola WHEN corrispondente, eseguire prima DEFAULT e quindi copiare le regole all'interno.
Per tutti i campi con una regola WHENNOT corrispondente, eseguire prima DEFAULT e quindi copiare le regole all'interno.

Il sistema elabora sempre le regole WHEN prima delle regole WHENNOT .
Per tutti i campi con i relativi valori modificati dal passaggio 1 e che contengono regole WHENCHANGED , eseguire prima DEFAULT e quindi copiare le regole all'interno.
Consentire all'utente di iniziare a modificare.
L'utente modifica un valore di campo e quindi sposta lo stato attivo dal campo.
Generare regole WHEN per quel campo che corrispondono al nuovo valore.
Generare regole WHENNOT per quel campo che corrispondono al nuovo valore.
Generare le regole WHENCHANGED per quel campo che corrispondono al nuovo valore.
Restituire la possibilità di modifica all'utente.
L'utente salva le modifiche apportate al database.
Per tutti i campi, eseguire operazioni SERVERDEFAULT definite per il campo direttamente o indirettamente in una regola WHEN o WHENNOT .

Voci di sequenza di tasti e valutazione delle regole

Il sistema imposta un nuovo valore per un campo ogni volta che un utente immette una sequenza di tasti all'interno di un campo tramite il modulo dell'elemento di lavoro. Ciò significa che una regola condizionale può verificarsi in modo imprevisto ogni volta che vengono soddisfatte le condizioni dei prerequisiti della regola.

Nell'esempio XML seguente, il sistema svuota MyCorp.SubStatus mentre si digita "Approved Again" nel campo Status perché la regola WHEN si verifica non appena l'utente digita la lettera "e" in Approved, anche se il valore finale previsto non è "Approva". Per questo motivo, valutare attentamente quando si usano regole condizionali.

<FIELD refname="MyCorp.SubStatus" />
   <WHEN field="MyCorp.Status" value="Approve" >
      <EMPTY />
   </WHEN>
</FIELD>

Condividi tramite

Regole e valutazione delle regole

Regole generate automaticamente

Regole di transizione dello stato

Transizioni di stato e regole di campo Per/Data

Regole dei campi Data modifica stato

Regole personalizzate

Composizione delle regole

Dove applicare una regola di campo

Cosa accade se sono definite troppe regole

Ignora regole

Campi di sistema e regole personalizzate

Regole predefinite e copiate

Regole vincolo

Elenchi di selezione

Valori o modifiche dei campi condizionali

Restrizioni relative alle regole di appartenenza a utenti o gruppi

Implementazione del processo

Usare i token per fare riferimento a utenti o gruppi

Valutazione delle regole

Ordine in cui vengono valutate le regole

Voci di sequenza di tasti e valutazione delle regole

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Regole e valutazione delle regole

Regole generate automaticamente

Regole di transizione dello stato

Transizioni di stato e regole di campo Per/Data

Regole dei campi Data modifica stato

Regole personalizzate

Composizione delle regole

Cosa accade se sono definite troppe regole

Ignora regole

Campi di sistema e regole personalizzate

Regole predefinite e copiate

Regole vincolo

Elenchi di selezione

Valori o modifiche dei campi condizionali

Restrizioni relative alle regole di appartenenza a utenti o gruppi

Implementazione del processo

Usare i token per fare riferimento a utenti o gruppi

Valutazione delle regole

Ordine in cui vengono valutate le regole

Articoli correlati

Commenti e suggerimenti

Risorse aggiuntive