Applicare una regola a un campo elemento di lavoro

Articolo
06/09/2015

A seconda del tipo di dati di un campo, è possibile impostare diverse restrizioni sui dati che è possibile immettere 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.

Tutti questi elementi regola possono essere definiti nella definizione FIELD di un tipo di elemento di lavoro, soggetto ad alcune restrizioni per i campi di sistema. Ad eccezione di HELPTEXT, è anche possibile specificare che queste regole devono diventare effettive durante una transizione del flusso di lavoro o come elementi figlio in un elemento FIELD (flusso di lavoro globale).

Regole di campo degli elementi XML di gestione degli elementi di lavoro

È possibile definire qualsiasi combinazione di regole per un campo, entro i limiti descritti in questo argomento.

Testo della Guida: specificare il testo delle descrizioni comandi da visualizzare in un form elemento di lavoro per un campo.

Elenco di selezione: specificare un menu a discesa o un elenco di selezione di valori consentiti, consigliati o non consentiti.

Regole di assegnazione valori: definire il comportamento e i vincoli in fase di esecuzione:

Cancellare, impostare come predefinito, copiare un valore o fare in modo che i valori corrispondano a un criterio
Richiedere, impostare come di sola lettura e limitare i valori assegnati a un campo
Limitare gli utenti che possono creare o modificare un elemento di lavoro

Regole condizionali: specificare quando un set di regole verrà applicato a un campo padre.

Impostazione di condizioni in base al ruolo utente: applicare regole in base a chi crea o modifica l'elemento di lavoro.

Uso di token per specificare un gruppo: specificare il dominio o l'ambito del gruppo usando il token corretto

Quali regole si possono applicare ai campi di sistema?

Come si possono evitare gli errori di convalida nei campi con nomi di persona?

È possibile definire un elenco di selezione multipla?

Dove deve essere applicata una regola di campo?

Come vengono valutate le regole? Quale ordine viene applicato?

In che modo le immissioni di sequenze di tasti in un form influiscono sulla valutazione delle regole?

Come si modificano i campi Stato e Motivo?

Come è possibile fare in modo che un campo contenga un valore che è la somma di altri due campi?

Quando si definiscono le regole dei campi con il flusso di lavoro globale?

Le regole dei campi sono un componente che permette di personalizzare la gestione degli elementi di lavoro. Per altre informazioni, vedere Personalizzare oggetti di rilevamento degli elementi di lavoro per supportare i processi del team.

Per informazioni sulla modifica dei campi o sull'aggiunta di regole dei campi a un file di definizione di un tipo di elemento di lavoro, vedere Modificare o aggiungere un campo per supportare query, report e flusso di lavoro.

Testo della Guida

È possibile personalizzare il testo della Guida o il testo delle descrizioni comando visualizzato quando un utente punta a un campo nel form di un elemento di lavoro. È possibile personalizzare e localizzare il testo della Guida per lo stesso campo visualizzato in tipi di elementi di lavoro e progetti team diversi. Il testo della Guida non può contenere più di 255 caratteri Unicode.

L'esempio seguente mostra l'assegnazione del testo della Guida a un campo Business Justification personalizzato:

<FIELD name=”Business Justification” refname="Fabrikam.BusinessJustification" type="String">
<HELPTEXT>Only required when you set the Urgencyfield to Need Immediately. </HELPTEXT>
</FIELD>

Per fornire agli utenti informazioni aggiuntive contenenti più di 255 caratteri, vedere Fornire testo della Guida, collegamenti ipertestuali o contenuto Web su un form elemento di lavoro.

Nota

La presenza di HELPTEXT si aggiunge alla dimensione dei dati archiviati e può influire sulla scalabilità.Se si supportano diverse centinaia di progetti team in una sola istanza di TFS, prestare attenzione all'uso di regole HELPTEXT.

Regole degli elenchi di selezione

Le regole degli elenchi di selezione definiscono i valori che un utente può o non può scegliere per un campo stringa. I valori definiti in un elenco di selezione vengono visualizzati nel form di un elemento di lavoro e nell'editor di query. È possibile combinare gli elenchi ed espanderli o comprimerli. È anche possibile usare gli attributi for e not per applicare o ignorare queste regole, in base all'utente che modifica l'elemento di lavoro.

Regola	Utilizzo
ALLOWEDVALUES	Limita i valori che un utente può scegliere in base ai valori specificati.
ALLOWEXISTINGVALUE	Consente a un campo di mantenere un valore esistente, anche se non si trova più in un elenco di selezione. È consigliabile includere questa regola quando si cambiano i valori del campo in un elenco di selezione o per gli elenchi di selezione contenenti nomi di persona.
GLOBALLIST	Specifica il nome di un elenco globale contenente valori mantenuti per un progetto team o un insieme di progetti.
PROHIBITEDVALUES	Impedisce l'assegnazione di valori specificati. L'elemento di lavoro non può essere salvato se il campo contiene un valore proibito.
SUGGESTEDVALUES	Definisce un elenco di valori tra cui gli utenti possono scegliere, ma che non sono obbligati a selezionare. Gli utenti possono specificare valori diversi da quelli di questo elenco.

Per alcuni esempi dell'uso degli elenchi di selezione, vedere Definire elenchi di opzioni.

Regole di assegnazione valori

Le regole di assegnazione valori definiscono il comportamento e i vincoli in fase di esecuzione, ad esempio specificare valori predefiniti, cancellare campi o richiedere che i campi siano definiti e altro. È possibile applicare o ignorare queste regole in base all'utente che modifica l'elemento di lavoro, con gli attributi for e not.

Cancellare, impostare come predefinito, copiare un valore o fare in modo che i valori corrispondano a un criterio

Queste regole consentono di configurare impostazioni predefinite, copiare valori da un campo a un altro o fare in modo che un valore di un campo corrisponda a un criterio prestabilito.

Regola	Utilizzo
COPY	Copia un valore specificato in un campo quando un utente crea o modifica un elemento di lavoro.
DEFAULT	Specifica un valore per un campo che risulta vuoto quando un utente crea o modifica un elemento di lavoro. Se un campo include già un valore, la regola DEFAULT verrà ignorata.
EMPTY	Cancella i valori contenuti in un campo e quindi lo imposta su modalità di sola lettura quando un utente salva l'elemento di lavoro. Non usare EMPTY con READONLY. EMPTY viene usato principalmente durante la transizione dello stato, per cancellare i campi applicabili allo stato finale della transizione dell'elemento.
MATCH	Impone alle voci immesse in un campo stringa di essere conformi a un criterio di caratteri o numeri specificato.
SERVERDEFAULT	Copia in un campo il nome utente corrente o il valore dell'orologio del server quando un utente salva un elemento di lavoro. Questi campi sono in genere visualizzati come di sola lettura nel form.

Per la struttura della sintassi e alcuni esempi, vedere Definire un valore predefinito o copiare un valore in un campo.

Richiedere, impostare come di sola lettura e limitare i valori assegnati a un campo

Queste regole definiscono le restrizioni per la specifica o la modifica del valore di un campo.

Regola	Utilizzo
CANNOTLOSEVALUE	Impedisce agli utenti di cancellare un valore da un campo una volta specificato.
FROZEN	Impedisce agli utenti di cambiare il valore di un campo una volta immesso. Quando un utente salva l'elemento di lavoro con un valore in quel campo, non sarà più possibile modificare il valore.
NOTSAMEAS	Impedisce di assegnare a un campo lo stesso valore assegnato a un altro campo.
READONLY	Impedisce di modificare un campo in alcun modo. Potrebbe essere necessario applicare questa regola in determinate condizioni. Ad esempio, dopo la chiusura di un elemento di lavoro, potrebbe essere necessario rendere un campo di sola lettura al fine di conservare i dati per la creazione di report. Non usare READONLY con l'elemento EMPTY, poiché EMPTY imposta anche un campo come di sola lettura. Se si combinano questi elementi, i risultati non saranno coerenti. È anche possibile rendere un campo di sola lettura dall'elemento di lavoro usando l'attributo ReadOnly dell'elemento Control. Sarà quindi possibile scrivere nel campo da altri client, ma non attraverso il form dell'elemento di lavoro.
REQUIRED	Richiede a un utente di specificare un valore per un campo. Gli utenti possono salvare un elemento di lavoro solo dopo avere assegnato valori a tutti i campi obbligatori.

Per la struttura della sintassi, vedere Riferimento a tutti gli elementi XML FIELD.

Limitare gli utenti che possono creare o modificare un elemento di lavoro

È possibile controllare chi può creare o modificare un elemento di lavoro applicando l'elemento VALIDUSER a campi con nomi di persona. Quando si specifica questo elemento, si indica quale utente o gruppo di utenti può essere assegnato come valore per il campo. È possibile impostare questo elemento per poter supportare l'attributo group facoltativo, che impone che la persona assegnata al campo sia un membro diretto o indiretto del gruppo specificato. Per impostazione predefinita, tutti i membri del gruppo Team Foundation Valid Users possono essere specificati nel campo.

L'elemento VALIDUSER è valido solo per i campi di tipo stringa. È possibile consentire o limitare l'applicazione della regola all'utente che modifica l'elemento di lavoro specificando un utente o un gruppo per gli attributi for o not, rispettivamente.

<VALIDUSER group="groupName" for="userName" not="userName" />

È possibile usare la regola VALIDUSER solo quando si fa riferimento a campi con nomi di persona. I campi di sistema seguenti sono esempi di campi con nomi di persona:

Attivato da (System.ActivatedBy)
Assegnato a (System.AssignedTo)
Autorizzato come (System.AuthorizedAs)
Modificato da (System.ChangedBy)
Chiuso da (System.ClosedBy)
Creato da (System.CreatedBy)

Oltre ai campi di sistema, è possibile creare un campo stringa personalizzato e usarlo come campo con nome di persona. È anche possibile sincronizzare con Active Directory i campi con nomi di persona personalizzati (specificare syncnamechanges="true").

I campi di un elemento di lavoro non distinguono le identità utente in domini diversi. Quindi, "Fabrikam\ctsoapo" e "Contoso\ctsoapo" vengono considerati lo stesso utente quando vengono immessi in un campo che usa la regola VALIDUSER.

Regole condizionali

Le regole condizionali consentono di specificare quando un set di regole verrà applicato a un campo padre. È possibile impostare le condizioni in base all'assegnazione (o mancata assegnazione) di un valore specificato a un altro campo o in base a quando un altro campo cambia (o non cambia). È possibile includere le regole per gli elenchi di selezione e l'assegnazione di valori in un elemento regola condizionale.

Regola	Utilizzo
WHEN	Specifica le regole da applicare al campo padre quando a un altro campo è assegnato un valore specificato.
WHENNOT	Specifica le regole da applicare al campo padre quando a un altro campo non è assegnato un valore specificato.
WHENCHANGED	Specifica le regole da applicare al campo padre quando cambia il valore di un campo specificato.
WHENNOTCHANGED	Specifica le regole da applicare al campo padre quando non cambia il valore di un campo specificato.

È possibile specificare più regole condizionali per campo, ma è possibile specificare un solo campo principale per regola condizionale. Non è possibile annidare le regole condizionali. Per la struttura della sintassi e alcuni esempi, vedere Assegnare valori e regole condizionali.

Applicare o ignorare le regole in base a chi crea o modifica l'elemento di lavoro

È possibile creare una regola per gli elenchi di selezione o l'assegnazione di valori da applicare o non applicare a un gruppo di utenti usando gli attributi for o not. Impostare un gruppo come ambito della regola. Per impostare più gruppi come ambito della regola, è necessario creare un gruppo TFS padre che includa il set di gruppi da usare.

Impostare un campo come obbligatorio solo per un gruppo specificato:

Usare for per applicare una regola a un gruppo. In questo esempio gli utenti del gruppo Junior Analysts devono compilare il campo Second Approver.
```
<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. Questo esempio definisce il campo Triage Description come di sola lettura per tutti gli utenti tranne quelli del gruppo Triage Committee.
```
<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>
```
Impostare un campo come obbligatorio per alcuni utenti e non per altri:

Usare una combinazione di for e not per applicare simultaneamente una regola ad alcuni e non ad altri. Questo esempio definisce Severity come campo obbligatorio per gli utenti del gruppo Project Members, ma non per quelli del gruppo Project Admins.
```
<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>
```
Poiché Deny ha la precedenza su Allow, se un utente fa parte di entrambi i gruppi, verrà applicata l'istruzione "not" e il campo non sarà obbligatorio.

Usare token per fare riferimento a gruppi

Quando si limita una regola a un gruppo, è necessario indicare il dominio o l'ambito del gruppo. Per alcuni valori, è possibile usare i token.

I campi con nomi di persona possono accettare valori che fanno riferimento sia a utenti che a gruppi. Gli attributi di campo, for e not, si applicano ai gruppi. Quando si specificano i valori per questi elementi, è possibile usare i token seguenti.

Impostare un progetto team come ambito - [Project]:

Il token [Project] viene usato per specificare un gruppo definito per un progetto team. Può corrispondere a un team, a un gruppo TFS predefinito, ad esempio il gruppo [Project]\Contributors, a un gruppo TFS personalizzato creato a livello di progetto o a un gruppo Windows aggiunto a un gruppo TFS. Ad esempio:
- Team: [Project]\Fabrikam Team
  
  Quando si crea un team, viene creato un gruppo TFS contenente i membri assegnati al team.
- Gruppo di progetto team: [Project]\Contributors
- Gruppo Windows aggiunto a un progetto team: [Project]\ Triage Committee
Suggerimento: per visualizzare un elenco di gruppi validi, aprire la pagina Sicurezza nel contesto di amministrazione di Team Web Access (TWA).
Impostare un insieme di progetti come ambito - [CollectionName]:

Usare [CollectionName] per referenziare un gruppo TFS impostato come ambito dell'insieme, ad esempio il gruppo Project Collection Administrators o un gruppo Windows aggiunto a un insieme. Ad esempio:
```
<FIELD name="Title">
<READONLY for="[DefaultCollection]\Project Collection Valid Users"/>
</FIELD>
```
Impostare un'istanza del server come ambito - [GLOBAL]:

Usare il token [GLOBAL] per referenziare un gruppo TFS impostato come ambito del server, ad esempio un gruppo predefinito o un gruppo Windows aggiunto a un gruppo a livello di server. Ad esempio:
```
<FIELD name="Title">
<READONLY for="[Global]\Team Foundation Valid Users"/>
</FIELD>
```
Specificare un gruppo o un account di dominio completo:

Il nome account di dominio completo, come quello dell'esempio seguente, può essere usato per referenziare un utente o 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"/>
```

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>

Domande e risposte

D: Quali regole si possono applicare ai campi di sistema?

R: I campi di sistema hanno nomi di riferimento Sytem.Nome, ad esempio System.Title e System.State. TFS limita la personalizzazione di questi campi, tranne nei casi seguenti:

La regola HELPTEXT può essere assegnata a tutti i campi.
La regola READONLY può essere assegnata ai campi Motivo e Stato.
La maggior parte delle regole può essere assegnata ai campi di sistema Titolo, Assegnato a, Descrizione o Modificato da.

D: Come si possono evitare gli errori di convalida nei campi con nomi di persona?

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

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

D: È possibile definire un elenco di selezione multipla?

R: Anche se questa funzionalità non è supportata a livello nativo, è possibile adattare il codice sorgente nel progetto CodePlex Controlli personalizzati per la gestione degli elementi di lavoro TFS.

D: Come si modificano i campi Stato e Motivo?

R: I campi Stato e Motivo vengono definiti nella sezione WORKFLOW della definizione del tipo di elemento di lavoro. È possibile specificare la maggior parte delle regole da applicare a un campo durante una modifica di 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.

D: Dove deve essere applicata una regola di campo?

R: Per applicare una regola a un campo per tutta la durata dell'elemento di lavoro, specificarla nella definizione FIELD. Ad esempio, un campo obbligatorio per un bug nuovo e attivo rimane obbligatorio fino alla chiusura del bug.

Altrimenti, specificare una regola da valutare solo durante una modifica nello stato. Queste regole vengono definite nella sezione WORKFLOW sotto gli elementi STATE, REASON o TRANSITION. Tutte le regole, tranne HELPTEXT, possono essere applicate in un elemento FIELD (flusso di lavoro).

Le regole dei campi sono additive, vale a dire che è possibile specificare per lo stesso campo quattro set di regole che verranno valutate dal motore per le regole dell'elemento di lavoro.

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 regola <REQUIRED /> esegue il controllo seguente:

"MyField Value" != NULL
Un'istanza di un elemento di lavoro viene impostata come ambito delle regole specifiche dello stato, quando è in un determinato stato. Una regola specifica dello stato viene applicata quando viene soddisfatta la condizione seguente:

State field value == "MyState" && "MyField Value" != NULL
Un elemento di lavoro sottoposto a una certa transizione viene impostato come ambito delle regole specifiche della transizione definite per 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
Un particolare motivo per una determinata transizione viene impostato come ambito delle regole specifiche del motivo definite per un certo motivo. Queste regole vengono elaborate quando vengono soddisfatte le condizioni seguenti:

Reason field == "MyReason" &&

State field value == "ToState" &&

"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

Nell'esempio seguente viene limitata la modifica del campo relativo alla gravità cliente quando l'elemento di lavoro è nello stato Attivo.

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

D: Come vengono valutate le regole?Quale ordine viene applicato?

R: Le regole vengono in genere elaborate nella stessa sequenza in cui sono elencate. Quando però si usano gli elementi WHEN*, DEFAULT e COPY, i comportamenti possono essere diversi.

È possibile farsi un'idea di come vengano valutate le regole quando si applicano più regole a un campo. La modalità di valutazione delle regole non è del tutto deterministica. Questa sezione descrive le interazioni e il comportamento previsti quando si usano le regole WHEN*, DEFAULT e COPY.

I passaggi seguenti mostrano, nella sequenza corretta, le interazioni eseguite da TFS e dall'utente di un form elemento di lavoro. Solo i passaggi 1, 8 e 13 vengono eseguiti dall'utente.

In un client Team Foundation, ad esempio Visual Studio, Team Explorer, Team Web Access o Team Explorer Everywhere, un utente crea un nuovo elemento di lavoro o ne modifica uno esistente.
Riempire i campi con le impostazioni predefinite. Per tutti i campi, usare le regole DEFAULT esterne alle regole WHEN*.
Copiare i valori dei campi. Per tutti i campi, usare le regole COPY esterne alle clausole WHEN*.
Per tutti i campi con una regola WHEN corrispondente, eseguire prima DEFAULT e quindi le regole COPY interne.
Per tutti i campi con una regola WHENNOT corrispondente, eseguire prima DEFAULT e quindi le regole COPY interne.

TFS elabora sempre le regole WHEN prima delle regole WHENNOT.
Per tutti i campi i cui valori sono stati cambiati dopo il passaggio 1 e che contengono regole WHENCHANGED, eseguire prima DEFAULT e quindi le regole COPY interne.
Consentire all'utente di iniziare la modifica.
L'utente cambia il valore di un campo e quindi sposta lo stato attivo dal campo.
Generare per tale campo le regole WHEN corrispondenti al nuovo valore.
Generare per tale campo le regole WHENNOT corrispondenti al nuovo valore.
Generare per tale campo le regole WHENCHANGED corrispondenti al nuovo valore.
Restituire all'utente la possibilità di eseguire modifiche.
L'utente salva le modifiche nel database.
Per tutti i campi, eseguire le operazioni SERVERDEFAULT definite per il campo in modo diretto o indiretto in base a una regola WHEN o WHENNOT.

D: In che modo le immissioni di sequenze di tasti in un form influiscono sulla valutazione delle regole?

R: Il sistema imposta un nuovo valore per un campo ogni volta che un utente immette una sequenza di tasti in un campo nel form dell'elemento di lavoro dell'interfaccia utente. Perciò una regola condizionale può venire eseguita in modo imprevisto quando vengono soddisfatte le condizioni essenziali della regola.

Nell'esempio di codice XML seguente, SubStatus verrà svuotato quando si digiterà "Approved Again" nel campo Status perché la regola WHEN* viene eseguita quando l'utente digita la lettera "e" di Approved, anche se il valore finale designato non è "Approve". Per questo motivo, prestare attenzione quando si usano le regole condizionali.

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

D: Come è possibile fare in modo che un campo contenga un valore che è la somma di altri due campi?

R: Questa funzionalità per il momento non è supportata in modo nativo.

D: Quando si definiscono le regole dei campi con il flusso di lavoro globale?

R: Usare il flusso di lavoro globale solo quando si ha il compito di gestire diversi campi con le stesse definizioni e regole in più progetti team. Come gli elenchi globali, il flusso di lavoro globale può ridurre al minimo il lavoro necessario per aggiornare le definizioni dei campi. Per altre informazioni, vedere Personalizzare il flusso di lavoro globale.

Vedere anche

Concetti

Riferimento a tutti gli elementi XML WITD

Altre risorse

Modificare o aggiungere un campo per supportare query, report e flusso di lavoro

Condividi tramite