1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 - Customizzare il process template, regole per i campi aggiuntivi dei WI
Nella quarta puntata abbiamo iniziato ad esaminare le regole che possono essere aggiunte ai campi di un Work Item. In questo link potete trovarne la lista completa ed in questo post cercherò di spiegare brevemente le più interessanti. Dato che nella scorsa puntata abbiamo parlato della regola ALLOWEDVALUES, è doveroso ora citare la ALLOWEXISTINGVALUE che non ha parametri, ma indica a TFS la volontà di mantenere un valore per il campo anche se non è più presente nella lista degli ALLOWEDVALUES. Se ad esempio la lista di valori ammessi viene cambiata rimuovendo un elemento, senza questa regola se qualcuno edita un Work Item che ha per questo campo un valore rimosso, viene forzato a cambiarlo. Con la presenza di questa regola, è possibile mantenere un valore anche non valido, ma chiaramente se viene cambiato deve essere comunque preso dalla lista dei valori permessi.
Analogamente alla ALLOWEDVALUES è presenta la PROHIBITEDVALUES che permette invece di specificare valori non permessi per il campo. Se ad esempio mettiamo nella lista il valore “blabla” e poi cerchiamo di salvare un workitem con quel valore abbiamo questo risultato.
Figura 1: Tentativo di salvataggio di un campo che ha un valore proibito.
Un’altra regola correlata al possibile contenuto è la SUGGESTEDVALUES, che in maniera analoga alla ALLOWEDVALUES permette di specificare una lista di valori, che in questo caso però sono però solamente “suggeriti”. L’interfaccia presenterà per il campo sempre una combobox, ma si può comunque scrivere qualsiasi altro valore. La CANNOTLOSEVALUE indica invece che la proprietà, una volta valorizzata, non può più essere portata a NULL.
La regola DEFAULT invece permette di specificare il valore di default, ed è decisamente molto flessibile.
Figura 2: Valore di default impostato come relativo ad un certo campo.
In Figura 2 vediamo infatti che la regola DEFAULT richiede per prima cosa il campo from che indica da dove TFS deve prendere il valore di default. In questo esempio abbiamo scelto il valore “field” che indica di prendere il valore di default da un altro campo. Scegliamo ad esempio il System.ChangedBy ed osserviamo cosa accade al nostro WI. Creiamo un nuovo bug, assegnamo un titolo e tutti i campi che vogliamo e quando salviamo vediamo che il valore del nostro campo, se non valorizzato, assume come default il nome del nostro utente corrente.
Figura 3: Quando andiamo a salvare un bug, se non valorizziamo il campo viene usato come valore di default il campo System.ChangedBy
Naturalmente è possibile specificare per il campo from della regola DEFAULT il valore value usato per specificare un valore di default testuale.
Figura 4: valore di default “classico”, in questo caso all’apertura del nuovo bug troverò già il valore “Default Value” indicato nel campo
Altri valori possibili per il campo from sono “currentuser” e “clock” usati rispettivamente per indicare l’utente corrente ed il timestamp corrente. La regola COPY è analoga alla DEFAULT, ma copia il valore sempre, anche se l’utente ha già valorizzato il campo. Infine un altra regola interessante è la FROZEN, la quale impedisce, dopo averlo valorizzato, di cambiare il valore di un campo. Questo significa che dopo avere per la prima volta inserito un valore valido, l’utente non può più modificarlo, ma può solamente azzerarlo.
Infine, un’altra regola utile è la MATCH, che permette di specificare un pattern per definire la validità del contenuto del campo.
alk.
