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
5 - Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
Nel post precedente è stata fatta una breve introduzione al concetto di Stati e Transizioni dei Work Item, ma ci sono molte altre funzionalità interessanti ancora da scoprire in questa area. Supponiamo che nello scenario del bug sia possibile passare da Triage a Closed solamente per gli amministratori di progetto. Questo requisito è abbastanza normale, perché un bug che va da Triage a Closed sostanzialmente non viene corretto e quindi ignorato, per cui questa decisione deve essere presa solamente da un Amministratore.
Figura 1: La transizione tra Triage e Closed viene ristretta solamente agli amministratori del progetto
Come vedete la soluzione è molto semplice, è sufficiente infatti editare i dettagli della transizione specificando nella clausola For la categoria di utenti che ha il permesso di effettuare la transazione, in questo caso gli amministratori del progetto. Questa soluzione è analoga a quanto visto negli articoli precedenti, sono molte infatti le parti dei Work Item che possono essere protette assegnandole solamente a specifici Security Groups.
Supponiamo ora di complicare leggermente lo scenario, vogliamo aggiungere un ulteriore campo chiamato “Rejected Reason”, in cui vogliamo inserire una descrizione dettagliata della ragione che ha portato qualcuno a chiudere il bug direttamente dallo stato Triage. Il primo passo è creare il nuovo campo ed aggiungerlo all’interfaccia.
Figura 2: Il campo aggiunto è però sempre editabile, per questa ragione potrei anche inserire la rejected reason alla creazione del bug
Come mostrato in Figura 2, purtroppo la Rejected Reason è sempre editabile perché è un normale campo aggiunto al Work Item, è necessario quindi andare a specificare che il campo può essere editato solamente nel caso un bug passi da triage a Closed. Se facciamo doppio click nello stato Triage, notiamo che si possono associare una serie di regole ai campi del WI; il significato è molto semplice, i questo modo possiamo specificare una serie di RULES che sono però valide solamente quando il Work Item si trova in questo stato specifico, per il resto valgono tutte le informazioni date sulle regole nei precedenti articoli.
Figura 3: Lo stato triage ha una regola sul campo Rejected Reason, in questo caso l’asterisco indica il READONLY
Per raggiungere lo scopo prefissato si deve inserire la regola READONLY al campo Rejected Reason in tutti gli stati ad eccezione di quello Closed, in questo modo il campo nell’interfaccia verrà reso editabile solamente quando lo stato è o viene spostato nello stato “closed”.
Figura 4: Quando sono in Triage non posso editare il campo, mentre basta spostarlo nello stato Closed che il campo diventa editabile.
A questo punto però il lavoro non è finito; sebbene si sia infatti associata la regola READONLY al campo Rejected Reason su tutti gli stati tranne che nel Closed, è comunque possibile editare il campo quando si passa dallo stato Fixed a Closed. Questa possibilità non deve essere data, perchè la rejected reason deve essere compilata solamente quando lo stato passa da Triage a Closed. Fortunatamente è possibile assegnare regole ai Field anche durante una transizione, è quindi sufficiente prendere la transazione tra Fixed e Closed ed imporre il READONLY del campo RejectedReason.
Figura 5: Dato che il campo Rejected Reason non deve essere editato durante la transizione tra Fixed e Closed, possiamo aggiungere una regola sul campo che vale solamente per la transizione.
Ora ci siamo avvicinati molto al risultato cercato, ma possiamo ancora migliorarlo. Gli ultimi requisiti richiedono che quando si passa dallo stato Triage al Closed, sia inserita come Resolved Reason il valore “Rejected”, ed inoltre che il valore Rejected Reason, sia richiesto se la Reason è differente da Duplicate. Queste richieste sono standard, prima di tutto il campo Resolved Reason deve assolutamente essere presente in tutti i bug ed è necessario che durante il passaggio da Triage a Closed, sia marcato come Rejected. Il secondo requisito è necessario perché quando il bug è duplicato non abbiamo necessità di una Rejected Reason (il concetto di duplicato non richiede ulteriori spiegazioni), mentre quando il bug è won’t fix oppure “Not reproducible” è solitamente necessario da parte di chi rigetta il bug indicare in maniera dettagliata la ragione del Reject.
I passi da seguire sono i seguenti, per prima cosa si edita lo stato Closed facendo si che il Resolved Reason abbia una regola REQUIRED, inoltre il campo Resolved Reason è messo nella UI come Readonly e quindi non è mai editabile direttamente dall’utente, ma solamente impostato dal sistema. A questo punto però è necessario fare in modo che durante la transizione il campo venga popolato correttamente.
Figura 6: Il campo Resolved Reason è readonly di default nella UI
Per far questo si deve andare nella definizione del campo ResolvedReason ed aggiungere il valore Rejected tra la lista dei possibili valori (regola ALLOWEDVALUES) ed infine è necessario aggiungere una regola di tipo COPY nel campo ResolvedReason associato alla transazione tra Triage e Closed.
Figura 7: Sequenza di passi per indicare che nella transizione tra triage e Closed il campo Resolved Reason deve assumere il valore Rejected.
In questo modo quando verrà effettuata la transizione tra lo stato Triage e Closed verrà applicata la regola COPY ed il valore del campo ResolvedReason verrà popolato automaticamente con il valore Rejected. Come si può vedere la regola COPY associata ad una transazione è il modo ideale per popolare automaticamente un campo in conseguenza di una transizione specifica.
Ora rimane da rendere il campo Rejected Reason obbligatorio solamente quando il valore del campo Reason è differente da Duplicate. Per fare questo si deve aggiungere un altro campo alla transizione Triage –> Closed ed usare una RULE di tipo WHEN NOT sul campo Rejected Reason. Questa particolare regola permette di applicare una serie di RULES solamente quando una condizione è falsa. In questo caso vogliamo applicare la regola REQUIRED solamente quando il campo System.Reason è diverso da Duplicate.
Figura 8: Aggiungere alla transizione la regola required solamente quando il campo System.Reason è differente dal valore duplicate
Come si vede in figura 8 è possibile indicare la condizione per cui il set di regole deve essere applicato (field System.Reason diverso da Duplicate) e poi nel tab Rules si possono specificare tutte le regole che si desidera, in questo cao che il campo Rejected Reson sia REQUIRED. Ora si può creare un nuovo bug in stato triage e salvarlo, poi cambiare lo stato in Closed e verificare che inserendo una Reason differente da “Duplicate” venga effettivamente richiesto di compilare il campo Rejected Reason.
Figura 9: Se cambio lo stato da Triage a Closed e la Reason è differente da Duplicate allora viene applicata la regola Required al campo Rejected Reason.
Se si cambia il campo Reason lasciando il Rejected Reason vuoto, si potrà vedere che la validazione del Work Item richiede la presenza del campo solamente quando la Reason è differente da duplicate. In Figura 9 a sinistra potete infatti vedere che il campo reason è Duplicate, e non è presente nessun errore di validazione. Nella parte destra invece si è cambiato il campo Reason in Not reproducible, ed immediatamente in altro si manifesta l’errore di validazione che richiede la compilazione del campo Rejected Reason.
Questo articolo è probabilmente il più complesso, ma mostra alcune funzionalità avanzate per la customizzazione del Work Item. Grazie al concetto di regole applicate agli stati o alle transazioni e soprattutto grazie alle regole condizionali, possiamo imporre regole ed automatismi complesse al workflow dei nostri Work Item, in modo che il team sia “aiutato” a seguire la corretta procedura di gestione bug, requisiti, o qualsiasi altro concetto esprimibile con un Work Item.
alk.