Condividi tramite


Regole e valutazione delle regole

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:

  1. Lo stato Chiuso è sempre contenuto nella categoria Stato completato .
  2. La categoria Stato completato non è configurabile ed è associata a uno e a un solo stato.
  3. Questo stato Closed è sempre Chiuso per i processi Agile e CMMI e sempre Fatto per i processi Scrum e Basic.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Composizione delle regole

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.

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.

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.

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.

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 .

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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

  4. Per tutti i campi con una regola condizionale corrispondente, applicare regole per impostare o copiare un valore di campo.

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

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

  7. Consentire all'utente di iniziare a modificare.

  8. L'utente modifica un valore di campo e quindi sposta lo stato attivo dal campo.

  9. Elaborare le regole When per quel campo che corrispondono al nuovo valore.

  10. Elabora le regole When Not per quel campo che corrispondono al nuovo valore.

  11. Elaborare le regole When Changed per quel campo che corrispondono al nuovo valore.

  12. Restituire la possibilità di modifica all'utente.

  13. L'utente salva le modifiche all'archivio dati.

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