Regole di campo disponibili

Aggiornamento: novembre 2007

Le regole di campo definiscono il comportamento e i vincoli dei campi. Queste regole sono elementi aggiuntivi elencati all'interno dei blocchi <FIELD></FIELD>. Ad esempio, se un campo è obbligatorio, il file XML che definisce il campo può avere il seguente aspetto:

<FIELD refname="System.Priority" name="Priority" type="String">
<HELPTTEXT>Enter the business priority of the bug</HELPTEXT>
<REQUIRED />
</FIELD>

Regole di campo disponibili

Per modificare il comportamento di un campo è possibile utilizzare le seguenti regole di campo:

<REQUIRED />

Il campo non può essere vuoto. È possibile contrassegnare come obbligatorio qualsiasi campo. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento REQUIRED (schema di definizione del tipo degli elementi di lavoro).

<READONLY />

Il campo non può essere modificato. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento READONLY (schema di definizione del tipo degli elementi di lavoro).

<EMPTY />

Il valore del campo viene annullato al momento del commit e l'utente non può inserire alcun valore. Questa regola viene utilizzata principalmente durante la transizione dello stato per annullare i valori dei campi relativi allo stato in cui viene eseguita la transizione. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento EMPTY (schema di definizione del tipo degli elementi di lavoro).

<FROZEN/>

Quando un campo dispone di un valore dopo il commit, il valore non può più essere modificato. Il valore del campo può tuttavia essere annullato utilizzando un vincolo <EMPTY/>. L'utente può annullare manualmente il valore contenuto nel campo, salvare l'elemento di lavoro e specificare un valore diverso al momento del ricaricamento. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento FROZEN (schema di definizione del tipo degli elementi di lavoro).

<CANNOTLOSEVALUE/>

Una volta che un campo ha acquisito un valore, non può essere cancellato o svuotato. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento CANNOTLOSEVALUE (schema di definizione del tipo degli elementi di lavoro).

<NOTSAMEAS field="MyCorp.Reviewer" />

Il valore del campo non può essere lo stesso valore contenuto in un altro campo; in questo caso, il campo "MyCorp.Reviewer”. Il valore deve essere rappresentato da un nome di riferimento di campo valido. Per ulteriori informazioni, vedere Nomi di riferimento di campo.

Esempi di utilizzo della regola NOTSAMEAS:

• Due campi non possono essere contemporaneamente vuoti.

• Il valore del campo "code reviewer" non può corrispondere esattamente al valore del campo "assigned to".

Utilizzare questa regola per campi di tipo simile. Non è possibile utilizzarla per campi in testo non crittografato o HTML. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento NOTSAMEAS (schema di definizione del tipo degli elementi di lavoro).

<VALIDUSER group="group" />

Il valore del campo deve essere un utente valido membro del gruppo Valid Users di Team Foundation.

Questa regola supporta l'attributo facoltativo group per specificare che l'utente deve essere membro diretto o indiretto del gruppo specificato. Per impostazione predefinita, la regola abilita tutti gli utenti che sono membri del gruppo Valid Users di Team Foundation. Per ulteriori informazioni, vedere Utilizzo dei token per il riferimento a utenti e gruppi. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento VALIDUSER (schema di definizione del tipo degli elementi di lavoro).

Nota:
Se la regola <REQUIRED/> non è specificata, questo campo accetta un valore vuoto. Viene utilizzata per i campi di tipo stringa.

Nota:
I campi degli elementi di lavoro non distinguono le identità degli utenti in domini diversi. Di conseguenza, "Example1\jaepak" e "Example2\jaepak" sono considerati lo stesso utente quando sono inseriti in un campo che utilizza la regola <VALIDUSER />. Le identità degli utenti sono tuttavia distinte dal dominio in altri punti di Team Foundation Server.

<ALLOWEXISTINGVALUE/>

Consente a un campo di mantenere un valore esistente, anche se tale valore non è più abilitato. Il comportamento alternativo e predefinito consiste nell'imporre all'utente l'inserimento dell''ultimo valore abilitato per il campo al momento della modifica. Questo elemento comporta solo la modifica degli elementi presenti nello stesso blocco. L'elemento non è in grado di accettare attributi for o not. Per ulteriori informazioni, vedere Elemento ALLOWEXISTINGVALUE (schema di definizione del tipo degli elementi di lavoro).

<ALLOWEDVALUES/>

Elenco enumerato di valori presentato all'utente sotto forma di elenco. Gli utenti devono selezionare uno dei valori presenti nell'elenco. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento ALLOWEDVALUES (schema di definizione del tipo degli elementi di lavoro).

<SUGGESTEDVALUES/>

Elenco enumerato di valori presentato all'utente sotto forma di elenco. Gli utenti possono selezionare uno dei valori. Gli utenti possono anche immettere un valore non compreso tra quelli suggeriti. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento SUGGESTEDVALUES (schema di definizione del tipo degli elementi di lavoro).

<PROHIBITEDVALUES/>

Gli utenti non possono salvare un elemento di lavoro se il campo contiene valori non consentiti. I valori non consentiti sono in genere utilizzati quando un valore era precedentemente consentito ma non è più valido. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento PROHIBITEDVALUES (schema di definizione del tipo degli elementi di lavoro).

<DEFAULT>

Quando un utente crea un nuovo elemento di lavoro o ne modifica uno, l'elemento <DEFAULT> inserisce un valore di campo se il campo è vuoto. Se è già presente un valore, la regola predefinita viene ignorata. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento DEFAULT (schema di definizione del tipo degli elementi di lavoro).

Nota:
Quando si modifica un elemento di lavoro, questa regola dell'elemento è non deterministica rispetto alla selezione del valore corrente o precedente da un altro campo.

<COPY>

Quando un utente crea un nuovo elemento di lavoro o ne modifica uno, l'elemento <COPY> inserisce un valore di campo a prescindere dai valori esistenti già presenti nel campo. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento COPY (schema di definizione del tipo degli elementi di lavoro).

Nota:
Quando si modifica un elemento di lavoro, questa regola dell'elemento è non deterministica rispetto alla selezione del valore corrente o precedente da un altro campo.

<SERVERDEFAULT>

A differenza di <DEFAULT> e <COPY> che inseriscono valori all'avvio della modifica, la regola <SERVERDEFAULT> inserisce un valore quando si esegue il commit dell'elemento di lavoro al database. Questa operazione viene eseguita al momento del salvataggio e l'utente non può eseguire l'override del valore. I campi appaiono come campi in sola lettura sul form. Questa regola viene utilizzata per campi come "Autore ultima modifica" e "Data ultima modifica" per supportare la traccia delle attività sicure. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento SERVERDEFAULT (schema di definizione del tipo degli elementi di lavoro).

<MATCH pattern="<pattern>"/>

Impone la corrispondenza del modello di base solo per le stringhe. <pattern> deve essere sostituito con il modello corrispondente. I valori validi sono "A,” "N,” "X”. Tutti gli altri valori vengono accettati come valori letterali. "A" rappresenta un carattere alfabetico. "N" rappresenta un carattere numerico. "X" rappresenta un carattere alfanumerico. Questo modello è supportato solo per i campi di tipo stringa. L'elemento accetta gli attributi for e not. Per ulteriori informazioni, vedere Elemento MATCH (schema di definizione del tipo degli elementi di lavoro).

Esempi di corrispondenza di modelli

Negli esempi riportati di seguito vengono illustrate le corrispondenze corrette ed errate dei modelli per una serie di campi:

Numero di versione

Modello: ANN.NN.NN

Convalida	R01.03.04 o V05.08.99
Convalida errata	1.3.4 o V5.8.99 o v1.3

Identificatore flessibile

Modello: XXX-XXX

Convalida	001-abc o a00-b02
Convalida errata	1-abc o 001.abc

Priorità

Modello: PN

Convalida	P1 o P5 o P9
Convalida errata	1 o P10

I tag di corrispondenza non prevedono la distinzione tra maiuscole e minuscole, per cui "PN" corrisponde sia a P1 che a p1.

Nota:
È possibile specificare più elementi <MATCH>. Se almeno un elemento viene riconosciuto come valido, il campo dispone di un valore valido.

Vedere anche

Altre risorse

Definizione degli elenchi campi