In questo post andremo ad esaminare come possiamo sfruttare il JQL per ottenere informazioni sul Worklog delle issue Jira.

Cosa offre il JQL standard

Partiamo come sempre dallo standard e cerchiamo di descrivere nel dettaglio quello che abbiamo a disposizione sul Worklog.

L’opzione deve essere attiva

Jira memorizza il Worklog nativamente. L’opzione deve naturalmente essere attivata (di default la abbiamo già abilitata) e questa possibilità la abbiamo a disposizione nella sezione di amministrazione della nostra instanza Jira (menù Issue).

I campi che referenziamo

Le informazioni che Jira memorizza sono le seguenti:

---

---

---

Che operazioni possiamo fare?

Con i primi tre campi che ho indicato, possiamo verificare quali issue presentano :

• Original estimate – Verificare quali issue presentano un particolare valore di stima impostata (valore esatto oppure maggiore o inferiore ad un valore)
• Remaining estimate – Verificare quali issue presentano una stima rimanente pari ad un valore esatto o maggiore o inferiore ad un valore
• Time spent – Verificare quali issue presentano un worklog caricato pari ad un valore esatto o maggiore o inferiore ad un valore;

In questo caso possiamo eseguire delle interrogazioni JQL del tipo:

<CAMPO> = <Valore> | <CAMPO> > <Valore> | <CAMPO> < <Valore>

<CAMPO> != <Valore> | <CAMPO> >= <Valore> | <CAMPO> <= <Valore>

esempi di alcuni possibili interrogazioni

Alcuni esempi

Riporto alcuni esempi di interrogazioni JQL per capire che cosa possiamo arrivare ad ottenere.

Cosa non possiamo fare

Non possiamo confrontare questi campi tra di loro. Se ad esempio impostiamo un JQL come nella seguente immagine:

lo standard purtroppo non ci supporta e ci restituisce un errore.

Per i restanti campi ….

…. possiamo eseguire delle operazioni di diverso tipo. Andiamo nel dettaglio.

---

---

---

Conclusione

Abbiamo visto alcuni esempi di utilizzo dello standard di JQ, dedicati al worklog. Se volete avere maggiori ragguagli, vi suggerisco di acquistare il mio libro su JQL:

Reference

Altre informazioni sono reperibili alla seguente pagina.

Sono sempre stato sensibile al JQL, ma per ovvi motivi. Dopo aver pubblicato un libro sull’argomento

ed ho anche avuto il privilegio di parlarne ad un webinar della WebGentle

Ma non è tutto ….

Ovviamente non è mai abbastanza. Infatti, una volta presa l’abitudine di usare JQL in Jira, sia sulle dashboard che nei filtri che nelle subscription, possiamo essere sicuri che andremo a cercare altre funzioni da poter utilizzare per poter estrarre i dati che ci interessano.

Parlo per mia esperienza e, sicuri del detto:

L’appetito vien mangiando

andiamo ad esaminare un altro addon che ci permette di poter aggiungere nuove frecce alla nostra faretra.

Enhanced Search (JQL & Subqueries)

Questo addon della Adaptavist permette di poter eseguire delle ricerche mirate attraverso l’introduzione di nuove funzioni JQL, che permettono di poter affinare le ricerche delle issue dei nostri progetti

Dalla pagina del marketplace sono riportare le nuove funzioni che vengono messe a disposizione dall’addon:

➡️ Functions

• dateCompare
• subtasksOf
• parentsOf
• linkedIssuesOf
• epicsOf
• issuesInEpics
• inSprint
• nextSprint
• previousSprint
• issueFieldMatch
• and more!

➡️ Keywords

• numberOfSubtasks
• numberOfLinks
• numberOfAttachments
• numberOfComments
• and many more!

Conclusioni

Queste funzioni permettono di poter ricavare delle issue facilmente e aiutano tutti gli utenti di Jira, dallo sviluppatore al Project Manager o anche il semplice fruitore di Jira, a identificare le issue che gli servono e permettono anche di poter gestire delle situazioni che, in precedenza, facevamo fatica a gestire. Non vedo l’ora di saggiare le potenzialità di questo addon CLOUD.

Mi permetto di sottolineare che nell’ultimo periodo abbiamo avuto una costante fioritura di addon per l’ambiente Cloud, che ci permette di poter fare un ventaglio di operazioni non indifferente. Sono sicuro che quanto prima, quanto offerto dall’ambiente Server/onPremise/Data Center sarà sicuramente offerto anche dal Cloud.

Reference

Maggiori informazioni sono disponibili presso la pagina del Marketplace.

IN questo post andremo a testare le ultime novità che sono state rilasciate da JSU, in particolare le nuove funzionalità che riguardano l’introduzione di JQL in alcune funzionalità.

Installazione

Partiamo come sempre dalla installazione. ANche in questo caso ci facciamo aiutare con una GIF, che ci mostra come eseguire l’installazione.

Faccio un piccolo appunto: La prima installazione che ho eseguito è andata in errore per un problema di spazio disco sul mio server di prova. Mea Culpa. Di conseguenza, sono stato costretto a riprenderla dato che l’installazione dell’addon risultava comunque eseguita ma non mi permetteva di poterla riprendere. Nella GIF trovate un altro metodo di installazione, dove vado a leggere il link dal marketplace e successivamente eseguo un upload.

Mi riprometto di analizzare questo punto in un post dedicato, e verificare come riuscire a gestire questa situazione.

Al termine della installazione, potrebbe essere richiesto di eseguire una operazione di Reindex, come mostrato dalla seguente GIF:

Configurazione

Proseguiamo con la configurazione generale. Con grande sorpresa ci accorgiamo che abbiamo una sola configurazione generale.

Questa configurazione prevede la possibilità di agganciarci alle API di Google Maps. Inserendo gli opportuni patrametri possiamo agganciarci.

Ma andiamo al sodo, andando ad analizzare quali opzioni ci aggiunge questo addon, Procediamo oltre alla configurazione via Workflow. Curiosiamo 😀

Prendiamo un Workflow di test, nel nostro ambiente Jira, ed andiamo ad esaminare le postfunctions. Questo è il risultato:

JSU mette da sempre a disposizione una serie di Postfunctions, ma adesso ha esteso queste funzionalità con l’introduzione del JQL.

Test

Procediamo con il test. Selezioniamo un progetto presente nel nostro ambiente di test e modifichiamo una post-fuction del Workflow…. sfruttando il JQL.

Vogliamo, nel dettaglio, che, quando chiudiamo una issue, se esistono issue di tipo EPIC e lo stato sia DONE, allora il campo Assignee sia ‘assegnato’ con il valore ‘lbianchi’.

Si tratta di un esempio in cui inserisco del JQL, per fare capire dove possiamo inserire il nostro … meraviglioso codice JQL 😀

Il risultato è riassunto nella seguente GIF:

Conclusioni

Abbiamo visto come possiamo inserire il codice JQL nel nostro Workflow. Si tratta di un esempio molto semplice e banale, ma sempre utile per capire dove possiamo inserire tali condizioni. Vi segnalo che, al momento, l’inserimento del JQL non è ancora assistito, ovvero non abbiamo lo stesso aiuto nello scrivere le query JQL come quando andiamo a fare la ricerca delle issue, ma sono sicuro che nelle prossime versioni la Beecom ci sorprenderà con effetti speciali. Sono Bravissimi e ogni giorno lo dimostrano sempre di più 🙂

Reference

Maggiori informazioni sono presenti nella pagina del marketplace.

Argomento spinoso

IN questo post andiamo a trattare un argomento spinoso, difficile e abbastanza complicato, che rigarda il GDPR.

Andiamo subito al dunque

Come tutti gli europei, sono stato omaggiato da uno tsunami di email per avvisarmi di questo nuovo tormentone pre-estivo. GDPR….. Ci siamo capiti. Vediamo come nella famiglia Atlassian ci si è adeguati con questo tormentone 🙂

Andiamo ad analizzare un addon della Communardo, un produttore che abbiamo già analizzato e che prontamente ci propone un nuovo addon. Iniziamo ad esaminarlo, tenendo conto di un concetto che, come sempre ripeto nei miei corsi, i prodotti Atlassian tracciano tutte le informazioni e di conseguenza collezionano diverse infomazioni degli utenti. La sfida è iniziata.

 

Attraverso User Anonymizer for Jira (GDPR) è possibile gestire queste situazioni. In particolare abbiamo la possibilità …

Anonymize user data across Jira to comply with the GDPR’s "Right to be Forgotten" with ease

ovvero di rendere anonimi i dati degli utenti su Jira, rispettando la regola del GDPR Diritto ad essere dimenticato.

Come vediamo, possiamo scegliere l’utente da (piccola licenza poetica) anonimizzare, e su quali situazioni. FAcile no?

In aggiunta ci permette di testare la configurazione prima di confermarla 😉

Carino ….

Possiamo anche utilizzarli in tantissime altre situazioni e scenari. Supponiamo di dover ‘nascondere’ degli utenti per esigenze di lavoro (utenti da non fare vedere all’esterno ad alcuni clienti).

Conclusioni

S P E T T A C O L O . 😀 Non vedo l’ora di provarlo. 😀

Reference

Questa volta abbiamo diverse referenze. Ve le cito tutte:

• Articolo della Communardo, che spiega tantissime cose interessanti ed introduce l’argomento
• La pagina dell’addon, con le indicazioni di base
• La pagina del marketplace, cui siamo già abituati.

Firenze …

In questo post andremo a raccontare questa prima giornata dell’Atlassian Team Tour .

 

Arrivato a Firenze ….

… mi sono subito unito alla squadra di esperti per gli ultimi ritocchi finali all’evento…

Un attimo di pausa prima dell’arrivo degli ospiti, dove ci si rilassa prima dell’inizio dell’evento 😀

Si parte subito con l’intervento di apertura di Vlad Cavalcanti.

sotto gli occhi di un pubblico attento

Una novità di questo evento è la presenza di un disegnatore che, su canvas, racconta e descrive quanto viene raccontato dai vari speaker

Abbiamo seguito attentamente quanto viene disegnato. Il disegnatore è stato bravissimo nel descrivere i punti chiave di ogni discussione.

Il disegno prende forma 😀

Segue l’intervento di Giulio Iannazzo, sulle infrastrutture Enterprise

che subito cattura l’attenzione degli ospiti

Il testimone passa a Cristian Berardi, di GetConnectes: Sponsor dell’evento.

Segue a ruota l’intervento di Paolo Serra …

… e di Peter Herzum di Herzum, il secondo sponsor dell’evento.

Ed ecco il risultato del disegnatore. Fantastico 😀

Segue l’intervento di Claudio Ombrella, che con grande professionalità racconta Jira a 0 a 10 anni in Autodesk.

raccontanto i record ed i risultati raggiunti da Autodesk quando ha adottato Jira 🙂

Lo stesso disegnatore fa molta fatica a riassumere i concetti espressi da Claudio 😛

ma il risultato è unico 😀

Intervento successivo è il mio: dedicato ai Team NON IT, ovvero a tutti coloro che hanno bisogno di prodotti Atlassian ma non sviluppano software

Non posso esimermi dal fotografare il risultato del disegnatore.

Conclusioni

Anche l’evento di Firenze è stato F E N O M E N A L E. Un grande pubblico ha seguito con molta attenzione e nella sezione finale, dove tutti gli speaker hanno risposto alle domande, non ha risparmiato frecciate e domande.

Si conclude questa esperienza fantastica e spero di ripeterla a breve.

Configurazione avanzata di Jira

In questo post andremo a visionare un addon che ci permette di gestire, in maniera molto più avanzata, i nostri progetti Jira.

Subito al sodo

Questo addon estende il concetto di Componente, arrivando a definire anche una gerarchia ad hoc, come mostrato in figura

permettendo di poter legare le versioni alle componenti

IN aggiunta abbiamo una estesione del JQL che ci permette di generare dei grafi delle versioni e in che relazioni sono tra di loro

Abbiamo a disposizione una reportistica adeguata

oltre che una estensione delle validazioni del Workflow, in modo da non risolvere le issue assegnandole alle versioni non corrette, come mostrato in figura.

Conclusione

Si tratta di un addon molto interessante. Non vedo l’ora di collaudarlo 🙂

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

Uso congiunto di Addons

In questo post andremo ad affrontare un argomento molto interessante : come usiamo in manieta congiunta più addons. Si tratta di una questione molto importante in quanto, in determinati ambiti/necessità, si vuole utilizzare due funzionalità di due addon differenti 🙂

Giusto per chiarire …

…. questo articolo è stato ispirato da un articolo molto bello, riportato da Rui Rodrigues e pubblicato nel blog della Xpand. L’obbiettivo di questo mio post è di riportare, in Italiano, quanto indicato. Si tratta di un Guest Post di Ihor Uksta della iDalko Software Developer ,Atlassian Platinum Solution Partner in Belgio.

Come sempre si tratta di una missione impossibile, ma la affrontiamo con coraggio e cerchiamo di riportare quanto descritto nell’originario, aggiungendo anche una serie di commenti necessari per chiarire o per meglio aiutare nella comprensione.

Iniziamo con le presentazioni

In questo post mostreremo come usare in maniera congiunta due addon molto interessanti. Il primo lo conosciamo molto bene e si tratta di Xporter. Lo abbiamo presentato e testato già in passato e, come tutti gli addon molto interessanti, ne seguiamo sempre tutte le evoluzioni 😀

Il secondo, non meno importante, è Table Grid, che permette di estendere Jira con funzionalità molto interessanti, che adesso andiamo a presentare:

Dalla precedente figura, vediamo che permette di poter inserire delle griglie che, sempre basandoci su quanti vediamo, possiamo inserire delle informazioni come le nostre spese e avere anche dei campi si totali/subtotali etc.

Permette di aggiungere dei campi speciali, come sequence, checkbox radio button, listbox fisse o dinamiche.

Permette di avere delle liste a cascata: i valori che trovi nelle liste successive sono conseguenza dei valori scelti nella lista precedente.

Come possiamo vedere si tratta di un addon molto interessante: lo testeremo  ben bene nei prossimi post.

 

Come possiamo usarli insieme?

Entriamo nel vivo di questo post 🙂 . Il Table Grid, permette di gestire dei campi Table, come abbiamo visto in precedenza. Si tratta si una  Driving Table, una opzione di Table Grid, che permette di inserire delle tabelle nelle issue. Nella figura seguente:

si tratta della tabella etichettata come Developer Rate.  Configuriamo questa tabella come segue, come mostrato in figura:

Una piccola digressione sulla configurazione, che richiede una spiegazione molto più dettagliata.

Spieghiamo le seguenti proprietà:

• gd.columns – stabilisce la lista, separata da virgole, delle colonne
• gd.tablename – Stabilisce il nome della tabella
• gd.ds – Il nostro datasource. Nell’esempio di tratta di Jira stesso.

For the first column, we’ll define the type ‘userlist’. It means that all your Jira users will be listed in a column. Afterwards, we can limit them to only one group ‘developers’, and set it as ‘required’ when inserting a row to the table.

Tutte le proprietà definite nell’esempio sono reperibili al seguente indirizzo.

Dettagliamo meglio le caratteristiche per definire una singola colonna:

col.developer.type=userlist
col.developer.required=truecol.developer.allow.roles = developers
col.developer.formatUser={username}
col.developer.autocomplete=truecol.rate=Rate
col.rate.type=number

(Vi rimando al test che eseguirò per un dettaglio più completo delle singole proprietà di una tabella, con tutte le spiegazioni: oramai vi ho abituato molto bene).

Andiamo adesso a definire un nuovo campo, per meglio mostrare il funzionamento di questo uso congiunto

andiamo a definire il valore di default

con la seguente configurazione.

gd.columns=developer,totalhours,startdate,enddate,salary
gd.tablename=teaminfo
gd.ds=jiracol.developer=Developer
col.developer.type=userlist
col.developer.required=true
col.developer.allow.groups = developers
col.developer.formatUser={username}
col.developer.autocomplete=true
col.developer.width=150col.totalhours=Hours Spent
col.totalhours.type = number
col.totalhours.formula = queries:value(‘jira’, “SELECT timeworked FROM worklog where created >=  ‘” + {startdate} + “‘ and updated <= ‘” + {enddate} + “‘ and author = ‘” +{developer} + “‘”) / 3600
col.totalhours.width= 120
col.totalhours.formatNumber = #.## h
col.totalhours.summary = sumcol.startdate=From
col.startdate.type=date
col.startdate.defaultDate = -1wcol.enddate=Till
col.enddate.type=date
col.enddate.defaultDate = +1dcol.salary=Salary
col.salary.type= number
col.salary.formatNumber = #.## $
col.salary.formula = queries:value(‘jira’, “SELECT rate FROM developer_rate_d2 where developer = ‘” + {developer} + “‘”) * {totalhours}
col.salary.summary = sum

Come possiamo osservare, si tratta di una configurazione che permette di definrie anche campi calcolati, interrogazioni al datasource definito, etc.

Terminata la configurazione, ed inserito il nuovo campo nelle opportune screen del progetto, possiamo sfruttare subito queste nuove informazioni

come mostrato in figura, ed arrivare a generare il report del team report issue, in maniera semplice e rapida.

ottenendo il seguente risultato

 

Adesso che abbiamo i dati …. Report

Passiamo subito al report. Qui entra in gioco Xporter che, come già indicato nei precedenti post, permette di definire il template da utilizzare

utilizzando i metatag tra {}. Quindi configuriamo il template:

Sempre nella fase di configurazione, andiamo a definire dove il template sarà disponibile, ovvero se lo sarà su esportazione, su bulk function, workflow post-functions, etc.

Manteniamoci sul semplice e andiamo ad usarlo solo nella fase di esportazione semplice della issue

ottenendo il seguente risultato:

Giudizio?

Una sola parola: S P E T T A C O L O. Abbiamo utilizzato la combinazione di due addon per generare un risultato spettacolare. Questo significa che possiamo generare dei report che permettono di riassumere tutta una serie di lavori in maniera ….. SEMPLICE. Non male come risultato.

 

Che altro?

Possiamo aggiungere diverse altre caratteristiche:

 

Table Grid Editor

• Datasource nell’esempio leggeva da Jira, ma potrebbe essere configurato per leggere i dati da un database separato ed incrociare i dati;
• Issue values placeholders to be used in formulas or SQL queries (issue id, assignee, etc.).
• Possiamo inserire dati dinamici da altri campi
• Il campo custom Table Grid Reader, che è in sola lettura, può essere compilato con query SQL.
• Campi custo Multi-Level Cascade , i quali hanno  drop-down dinamici popolati attraverso query SQL i quali potrebbero avere delle dipendenze tra di loro. Questo è anche compatibile con Service Desk.
• Java and Rest API sempre diponibili.

Xporter

• Esportare in formato PDF, XLSX, PNG, DOC, CSV ed altri ancora.
• Esportare altre informazioni quali linked issues, sub-tasks, commenti, worklogs, allegati ed altro ancora.
• Generare documentazione basata su un insieme di più issue.
• Creare ed inviare documenti via mail verso un file server.
• Post-functions to trigger export event on issue transitions.

Come potete vedere abbiamo tantissime possibilità di espandere questo esempio al fine di coprire le nostre necessità.

 

Conclusioni

Abbiamo visto un uso congiunto di due addon e di come ci possono aiutare nella vita di tutti i giorni. Nei prossimi post cercheremo di mostrare molto più nel dettaglio altri utilizzi congiunti 🙂

 

Reference

Vi riporto l’articolo originario della portoghese XPand, che potete reperire al seguente indirizzo.

 

Action Reminders per Jira

In questo post andremo a testare questo addon, che permette di gestire dei reminder automatici per Jira, il quale, attraverso opportune interrogazioni, permette di segnalare a determinati utenti per segnalare determiante condizioni quali:

• issue ancora aperte dopo X giorni
• issue che rispondono a determinate condizioni
• etc.

Installazione

Partiamo, come sempre, dalla installazione dell’addon. Procediamo con il ricercarlo nell’elenco dei vari addon.

Dato che si tratta di un addon gratuito, come conseguenza non dobbiamo generare alcuna licenza e, per nostra gioia, l’installazione è molto più semplice. Selezioniamo Install ….

… una volta terminata l’installazione …

… abbiamo il messaggio finale che ci dice che l’addon è pronto per essere usato.

Passiamo alla configurazione.

 

Configurazione

Proseguiamo con la configurazione dell’addon. Iniziamo, come sempre, dalla configurazione generale. Notiamo che abbiamo un nuovo menù nella sezione Addons.

Se lo selezioniamo, visualizziamo subito la pagina di configurazione:

dove andiamo ad abilitare l’addon stesso (primo parametro), attivarlo a livello di schedulatore (secondo parametro), messo a disposizione dall’addon, e quanti valori deve estrarre il JQL che verrà impostato per il reminder (terzo parametro).

In alto ai tre parametri, abbiamo tre icone che identificano altre opzioni:

• Help on line
• Impostazioni
• Configurare  lo schedulatore

La figura successiva ci fornisce un altro tooltip.

Passiamo all’utilizzo vero e proprio.

 

Test

Iniziamo con l’utilizzo. Notiamo che nelle impostazioni del progetto abbiamo una nuova voce di menù, come mostrato in figura:

Quando la selezioniamo, viene visualizzata la maschera di gestione delle schedulazioni:

Selezionando il bottone +, siamo rediretti nella pagina di generazione del nostro reminder, ovvero della query JQL che ci aiuta nella identificazione delle issue.

Una volta impostato il mostro reminder, abbiamo tutto.

 

come possiamo vedere dalla precedente figura, abbiamo impostato un reminder e questo viene eseguito secondo la schedulazione (modello Crontab).

Conclusioni

Questo addon presenta una caratteristica molto interessante. Permette di poter impostare dei reminder basati su JQL. A differenza del precedente addon esaminato, abbiamo la possibilità di ricercare issue basate su condizioni che ci interessano. Nei prossimi post tenteremo di dare una ulteriore indicazione, ovvero cercheremo di dire quando usare uno o l’altro.

Reference

Maggiori informazioni sono reperibili alla pagina del marketplace.

Action Reminders per Jira

In questo post andremo ad esaminare un addon che permette di gestire dei reminder automatici per Jira, il quale, attraverso opportune interrogazioni, permette di segnalare a determinati utenti per segnalare determiante condizioni quali:

• issue ancora aperte dopo X giorni
• issue che rispondono a determinate condizioni
• etc.

Cosa mette a disposizione

L’addon permette di definire in maniera molto semplice, attraverso una interfaccia semplice e diretta:

definisce quali azioni intraprendere e chi avvisare attraverso mail.

La configurazione risulta molto semplice e diretta.

Conclusioni

Abbiamo a disposizione un addon molto interessante da esaminare. Avevamo già affrontato l’argomento in altri ambiti, per creare dei reminder automatici con le funzioni out-of-the-box.

Reference

Maggiori informazioni sono reperibili alla pagina del marketplace.

Campi Custom e database

In questo post andremo ad esaminare un addon particolare. Si tratta di nFeed, della Valiantys. Questo addon permette di realizzare delle funzioni particolari e permette di mettere in comunicazione i campi personalizzati ed i database. Andiamo a curiosare.

Installazione

Partiamo come sempre dalla installazione del nostro addon. Lo cerchiamo dalla lista degli addon che possiamo installare, come mostrato in figura:

Selezioniamo Free trial per attivare la procedura di installazione ….

… al completamento, procediamo con la generazione della licenza trial ….

… una volta applicata la licenza, attendiamo che sia visualizzato il messaggio di conclusione delle operazioni:

Al termine della installazione …

… sarà visualizzato il seguente messaggio.

che richiede di eseguire una reindex dei campi. Questo è causato dal fatto che l’addon aggiunge nuovi tipi di campi. Basta eseguirla e siamo quindi pronti per passare alla fase successiva 🙂

 

Configurazione

Passiamo alla configurazione generale dell’addon. Si tratta di eseguire tutta una serie di operazioni per poterci connettere alle sorgenti dati, selezionare quali informazioni prendere e come gestire le informazioni.

Possiamo accedere alla configurazione o tramite il menù Addons o selezionando il tasto Configure presente nell’elenco degli addon installati, come mostrato in figura:

Una volta selezionato, questo è quanto ci appare:

Da qui possiamo eseguire tutte le operazioni per preparare il nostro sistema. Iniziamo ad esaminarle con estrema calma :-), dato che è importante. Partiamo da DATASOURCES.

Si tratta della opzione che ci permette di definire le nostre sorgenti dati. Da qui andiamo a definire dove andiamo a leggere le informazioni.

 

Andiamo a definire un datasource di test, per verificare l’addon. Leggeremo i dati sul database del Jira Locale.

Fatto questo, andiamo a definire un campo custom, selezionando la seconda opzione CONFIGURE FIELDS.

L’addon si appoggia alla gestione standard di generazione dei campi. Selezionando Create a custom field siamo reindirizzati nella sezione dei campi custom. Se andiamo a generare un nuovo campo personalizzato, notiamo che esistono diversi nuovi tipi:

Selezioniamo un tipo di campo, il primo della lista e procediamo con la nostra configurazione.

Una volta creato il campo, andiamo a definire …. cosa legge il nostro campo e che cosa propone. Selezioniamo la Configuration/Fields, in modo da definire la query 🙂

Primo passo è sempre appoggiarsi al Datasource che abbiamo definito in precedenza.

Quando lo andiamo a selezionare, l’addon ci propone l’elenco, come mostrato in figura:

Fatto ciò, possiamo definire la query 🙂

Possiamo scegliere diversi modi, in questo caso, di interrogare il database. JQL, SQL, Chiamate REST. Abbiamo possibilità infinite 😀

Scegliamo SQL nel nostro test.

Se selezioniamo Tables, andiamo a leggere il catalogo delle tabelle del DB, come mostrato in figura:

In questo esempio andiamo a definire una query sull’elenco delle priorità.

Confermiamo il tutto. La nostra configurazione è terminata. Passiamo al test

 

Test

Dopo questo trattato sulla configurazione, passiamo al test. Selezioniamo un progetto nel nostro ambiente di prova, ci posizioniamo su di una issue ed andiamo ad aggiungere un campo, selezionando sulla view issue il tasto Add Field . Cerchiamo il nostro campo:

Già subito possiamo notare la potenza di questo addon. Possiamo selezionare direttamente il valore da assegnare al campo e vediamo che il risultato è strabiliante 🙂

Se agiamo dalla issue view, questo è il risultato:

 

Conclusioni

Molto molto molto molto interessante. Abbiamo esaminato un addon che permette di eseguire delle operazioni molto importanti. Possiamo usarlo per leggere informazioni in maniera dinamica. Nei prossimi post cercheremo di capire ulteriori sviluppi e limiti e casi particolari.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.