JIRA e le sue tabelle

In questo post, proseguiamo quanto iniziato su questo post, dove abbiamo fatto una breve panoramica delle tabelle di Confluence.

In questo caso, proviamo ad eseguire la stessa operazione presentata nel post precedente, ma facendo riferimento alle tabelle di JIRA. La seguente immagine riassume alcune delle tabelle di JIRA. Si rimanda alla sezione Reference per tutte le indicazioni sul caso.

Precauzioni

Si ribadiscono le stesse identiche precauzioni che sono state indicate nel precedente post. Fate sempre un backup dei dati, prima di procedere con qualsiasi operazione. In questo modo potete essere sicuri di poter operare in tutta sicurezza.

Iniziamo 🙂

Cerchiamo di impostare un avatar di default differente da quello preimpostato. Partiamo da questa situazione:

Le tabelle che andiamo a referenziate sono le seguenti:

• cwd_user – Tabella contenente le informazioni degli utenti
• avatar – contenente gli avatar standard
• propertyentry – contenente le associazioni da utente ed avatar utilizzato
• propertynumber – contenente l’associazione con l’avatar collegato all’utente

Procediamo con la modifica

Aggiungiamo il nuovo avatar. Il file va caricato nella directory:

<Install-Dir>Atlassian-JiraWEBINFClassesAvatar

Supponiamo di utilizzare sempre l’icona del pinguino 🙂

Punto di attenzione. A differenza di Confluence, JIRA ha la necessità di avere anche una seconda icona, dimensione 24×24, la metà rispetto alla dimensione dell’avatar che si inserisce, ovvero 48×48, che viene referenziato e mostrato in alto a destra. Predisporre quindi un secondo avatar, nome pari a small_<nome_del_file_nuovo_avatar>.png e memorizzarlo nella stessa directory.

Quindi aggiungiamo un nuovo record, alla tabella avatar, con le indicazioni dell’icona nuova

Dalla tabella cwd_user, identifichiamo l’utente in questione:

Dalla propertyentry ci ricaviamo l’ID per determinare la proprietà da andare a modificare, cercando per ENTITY_ID = ID USER e PROPERTY_KEY = ‘user.avatar.id’:

Quindi dalla propertynumber, ci ricaviamo l’ID dell’avatar utilizzato.

Inseriamo, nel campo propertyvalue, l’ID del nuovo avatar di default, e questo è il risultato:

Conclusioni

Con questo sistema riusciamo ad impostare il nuovo avatar di default in maniera semplice. Questo ci consente di poter eseguire una semplice modifica alla installazione, sostituendo gli avatar in modo semplice.

Se si vuole aggiungere un avatar non di default?

Fattibile, ma occorre agire da tutt’altra parte. In questo caso si dovrebbe memorizzare il file del nuovo avatar in altra directory, ovvero:

<JIRA-Home-dir>dataavatars

e si memorizzano in vari formati, principalmente il formato 48×48 ed il formato 24×24, che servono principalmente per tutte le funzionalità. La configurazione delle tabelle è la medesima. Il nome del file, come per il precedente esempio, deve essere preceduto dal nuovo ID assegnato alla tabella Avatar. Nei prossimi post vedremo altre informazioni sulle tabelle di JIRA.

Scaviamo in profondità

In questo post andremo a vedere, con alcuni esempi, come possiamo accedere ai dati di Confluence e JIRA, lavorando direttamente su DB. In particolare vedremo alcuni esempi di come sono memorizzate le informazioni. In figura vediamo lo schema delle tabelle di Confluence.

Perché accedere ai dati?

Prima di iniziare ad esplorare le tabelle dei due sistemi, conviene porsi una domanda fondamentale: Perché dobbiamo accedere direttamente ai dati del DB? Quale è la necessità?

Uno dei motivi più importanti è sicuramente quello di dover accedere ad informazioni a cui non si avrebbe altrimenti accesso, oppure il dover eseguire una operazione massiva. Questo perché non sempre è possibile eseguire una operazione su di una grossa mole di dati, in quanto Confluence/JIRA non la consentono, come ribadito in altri post di questo blog. Fino a quando non saranno disponibili delle funzionalità di un certo tipo, occorre dover agire direttamente da DB. In aggiunta, queste informazioni sono sicuramente utili a coloro che vogliono sviluppare addon per i prodotti Atlassian 🙂

Precauzioni

Prima di agire, occorre sempre che siano prese delle semplici precauzioni. Il motivo mi sembra abbastanza semplice: Quando si lavora direttamente su DB, è abbastanza facile arrecare danni. Di conseguenza, sempre meglio avere un backup dei dati/tabelle/DB intero prima di procedere con le modifiche.

Il mio consiglio è sempre quello di avere a disposizione un backup del DB completo + una copia delle tabelle su cui si agisce, prima di procedere con qualsiasi operazione.

Un primo esempio

Supponiamo che si voglia modificare gli avatar standard, con un avatar differente (i motivi possono essere qualsiasi: Marketing aziendale,  impostare un avatar di default più carino, etc).

Al momento, solo gli utenti possono modificare il proprio avatar. A livello di amministrazione, non è possibile eseguire tale operazione. La precedente immagine mostra dove è possibile eseguire tale operazione. Adesso vediamo come è possibile aggirare tale limitazione, semplicemente andando a lavorare su DB.

In prima battuta esaminiamo le tabelle dove sono contenute le informazioni delle utenze. In particolare faremo riferimento a:

• cwd_user – Tabella contenente le informazioni degli utenti che sono stati configurati in Confluence.
• cwd_group – Tabella contenente le informazioni dei gruppi definiti su Confluence.
• os_propertyentry – Tabella contenente anche le informazioni degli avatar.
• user_mapping – Tabella contenente la corrispondenza uid – nome utente.

La tabella che ci interessa in particolare è l’ultima. Dobbiamo andare a cercare le informazioni degli avatar, utilizzando questa query:

Come si vede dalla precedente immagine, quello che dobbiamo andare a cercare è il campo String_val. In questo campo è presente la localizzazione dell’avatar. In questo caso ho assegnato un avatar di default. 🙂 Nel campo Entity_name abbiamo la userid. Come possiamo vedere è abbastanza ….. criptata. Come facciamo a decodificarla? Il giro è il seguente:

• Dalla tabella os_propertyentry abbiamo le indicazioni del path della immagine
• Dalla tabella user_mapping abbiamo le indicazioni dell’uid dell’utente
• Dalla tabella cwd_user abbiamo il nome dell’utente.

Le seguenti immagini chiariscono il tutto: Dall’ID identifichiamo l’utente

Di conseguenza, per modificare l’avatar dell’utente admin (in questo caso), possiamo semplicemente modificare il path e andare ad assegnarne uno nuovo. Supponiamo di creare una sottodirectory nel path utilizzato da Confluence per gestire gli avatar di default, ovvero:

<Install_dir_Confluence>confluenceimagesiconsprofilepic

supponiamo di chiamarla Demoprofile e di memorizzare il seguente avatar:

Eseguire il restart del servizio Confluence e, come per magia, il risultato sarà il seguente:

Conclusioni

Abbiamo visto un esempio di come si può modificare il database per modificare gli avatar degli utenti di Confluence. Questo esempio può essere utilizzato anche per le installazioni per cui gli utenti sono presi da LDAP e non sono solo utenti locali di Confluence.  Nei prossimi post vedremo altri esempi di come si può accedere ai dati e …. vedere altre informazioni.

Proseguiamo il nostro piccolo tour nei vari plugin di Confluence e Jira onDemand, iniziato in questo post.

Confluence

Viene data la possibilità di poter visualizzare delle formule matematiche attraverso Beautiful Math for Confluence.

Addon utile per coloro che fanno parecchio uso di formule matematiche o che devono usare LaTeX, ma non è il solo. Segnalo anche il plugin Bulk Action Tools, che rappresenta una vera sopresa :-). SI tratta di un addon che consente di centralizzare delle azioni altrimenti brigose (tipico termine bolognese che sta ad indicare azioni che richiedono molto tempo e sono noiose)

A volte non se ne intravede l’importanza, ma queste operazioni sono abbastanza noiose se si utilizzano le funzionalità standard. Questo perché tali funzionalità sono letteralmente sparse tra le varie componenti. Come già ribadito in questo post, la centralizzazione di certe operazioni è importante, sopratutto quando si riesce a semplificare la vita degli utenti rendendo le funzioni molto più agevoli :-D.

Non meno importante è la funzionalità di Copy Space. Funzione utilizzatissima nella versione server (ve lo posso assicurare).

Anche se non è meno importante del Copy Page Tree, il quale consente di poter copiare solo porzioni di space, in particolare una pagina e la sue sottopagine.

Chiudiamo questa carrellata di Addons con il Balsamiq Mockups for Confluence. Già disponibile nella versione Server, consente di poter realizzare dei mockups per qualsiasi ambito (ad es. mockups di applicazioni, schemi, semplici workflow, etc.)

JIRA

Iniziamo citando JQL Pro, un addon che consente estende, con ulteriori funzionalità, il JQL di JIRA

Proseguiamo il nostro tour citando l’addon Plain Tasks – Simple Todo Lists, un semplice addon che consente di poter semplificare la complessità di JIRA e trasformarla in un a più semplice ToDo List. Questo potrebbe essere utile per poter mettere a disposizione di utenti non avanzati, le funzionalità avanzate di JIRA.

Chiudiamo la carrellata degli addon di JIRA con Automated Log Work for JIRA. Si tratta di un addon che consente di poter automatizzare la fase di worklog. Al momento JIRA consente un inserimento manuale, mentre attraverso questo addon, è possibile automatizzare tale fase e delegare a JIRA la fase di conteggio del tempo dedicato ad ogni task.

Conclusioni

Come possiamo osservare, anche gli addon della versione Confluence/JIRA onDemand iniziano a prendere piede e comunciano a fornire funzionalità molto avanzate. Le sorprese non sono finite qui. Nei prossimi post andremo ad esaminare nel dettaglio questi addon.

Nuove Features 2.0

Prosegue, in questo post, la panoramica sulle funzionalità di JIRA Service Desk, già descritte nel primo post e proseguite nel successivo, dove è stata descritta la possibilità di poter utilizzare il JIRA Service Desk per gestire delle risorse riusabili.

Un passo indietro

Tramite questo Addon, si estende JIRA affinché possa divenire un sistema di Trouble Ticketing ma non solo. Attraverso l’uso di Confluence e dei suoi Addon, è possibile sfruttare JIRA per tracciare anche altri eventi e poter essere di supporto per i team di sviluppo.

Novità – Pagamento in base agli agenti

Viene rivisto il modello di pagamento in base agli utenti. Si inizia a distinguere tra tre ruoli ben distinti:

• Agenti, ovvero gli utenti che accedono al sistema e che si occupano di gestire le segnalazioni ricevute
• Clienti, ovvero coloro che inviano le segnaklazioni
• Admin, ovvero gli amministratori del sito

Il pagamento viene calcolato in base al numero di agenti (minimo 3) di cui si intende disporre. Ogni agente può gestire un numero di clienti illimitato.

Migliorato il Portale di accesso al JIRA Service Desk

Risulta migliorato il portale di accesso alle richieste. Questo non deve essere visto come un qualcosa di dedicato solo alle richieste IT (nuovo software da installare, problemi con le stampanti, etc), ma viene esteso anche ad altre problematiche/tipologie di richieste. In precedenza avevo già citato un esempio di come è possibile utilizzare questo addon per tracciare le risorse riusabili :-).

 Richieste via email

Viene migliorata e resa più semplice la funzionalità di generazione delle richieste via email. In questo modo, si facilita l’uso dello strumento anche per le persone che sono più abituate ad usare l’email. Pochi semplici passi e l’email viene configurata. JIRA dispone nativamente di questa funzionalità e l’addon consente di poterla configurare senza tanti problemi 🙂

 Migliorate le pagine di gestione

Sono state migliorate, e rese molto più semplici, le pagine di gestione e le pagine utilizzate dagli agenti per poter svolgere la propria mansione. In questo modo si aumenta e facilita la produttività degli Agenti.

Conclusioni

Un addon fenomenale. Non posso che consigliarlo per le piccole o grandi imprese che intendono crearsi un proprio sistema di Service Desk interno che, in maniera agevole e semplice, possa aiutare le persone a risolvere i piccoli e grandi problemi quotidiani.

JIRA Capture

In questo post andremo ad esaminare un addon di JIRA, molto utile per le sessioni di testing. JIRA CAPTURE. Nato come addon delle prime versioni di JIRA, fu succesivamente acquisito dalla Atlassian (insieme ad altri addon) e gli fu cambiato nome in JIRA Capture.

Nel dettaglio ….

Questo Addon consente di poter velocizzare i feedback e renderli molto più agevoli. Proviamo a descrivere uno scenario. Supponiamo di dover eseguire un test di un applicativo WEB. Supponiamo di aver identificato un punto in questo applicativo, in cui sia necessario un intervento (sia esso di manutenzione, correttivo o migliorativo. Come procediamo?

I passi sono semplici ma brigosi:

• Creare uno screenshot della pagina web
• Evidenziare il punto o i punti su cui si vuole eseguire l’intervento
• mail per il servizio di manutenzione o creazione del task su JIRA, se si dispone di quest’ultimo

Immaginate di doverlo ripetere diverse volte al giorno……

In che modo JIRA Capture ci aiuta?

Semplice. Automatizza questa operazione. 🙂 Si tratta di un componente della suite dei prodotti Atlassian, che si interfaccia su tutti i maggiori browser in circolazione e, una volta richiamato, esegue tutte le operazioni che ho descritto in precedenza ed attende solo che l’utente inserisca il testo del feedback che intende fornire.

Come evidenziato dalla precedente immagine, JIRA Capture mette a disposizione tutti gli strumenti per

• evidenziare i punti di intervento sullo screenshot
• inserire le annotazioni del caso
• Creare una issue nuova
• Accodare le informazioni ad una issue preesistente

Conclusioni

Si tratta di un valido strumento che aiuta nello sviluppo e nel fornire un feedback.  Nei prossimi post vedremo nel dettaglio il funzionamento e mostreremo un esempio di come si può utilizzare.

Data Center Deployment

The Data Center deployment option is designed for high availability and performance at scale when hosting our applications in your own data center.

In questo modo viene presentata la versione per Datacenter, rilasciata ad inizio settembre 2014, dei seguenti prodotti:

• Confluence
• Jira
• Stash (Beta)

studiata e predisposta per funzionare in ambienti datacenter per alte prestazioni, per alto numero di utenti e mission critical.

Questa versione dei prodotti Atlassian  e stata studiata in modo da poter fornire migliori performance, mettere le aziende in condizione di fornire un servizio sempre disponibile e fornire una buona scalabilita del prodotto.

Maggiori informazioni sono raccolte nel seguente video:

https://www.youtube.com/watch?v=Va9yGtqzb14

Conclusioni

Attendiamoci nuove sorprese dalla Atlassian. Sono sicuro che a breve ci saranno ulteriori novità. 🙂

Una piccola panoramica

Affrontiamo, in questo post, una piccola panoramica di vari addon, che sono a disposizione della versione onDemand di Confluence e Jira. In questo modo, esploriamo ulteriormente quali funzionalità sono state incluse di recente e riscopriamone altre.

Confluence

Si parte da Google Maps for Confluence, che consente di poter aggiungere le Google Maps nelle pagine di Confluence, comprensiva di Street View, come mostrato nelle seguenti immagini:

Si continua per il Comala Canvas for Confluence, che consente di poter inserire delle schede (sull’esempio di Jira AGILE BOARD) su Confluence, come mostrato nelle seguenti figure.

Citiamo anche vSecure, un semplice addon che consente di poter criptare/decriptare informazioni all’interno di pagine Confluence:

JIRA

Partiamo citando l’addon Aha! Visual Product Roadmaps, che consente di poter creare delle roadmap interattive molto belle.

Citiamo Gantt Cloud, che consente di poter generare dei grafici GANTT su Jira, come mostrato dalle seguenti figure:

Conclusioni

Non possiamo che notare con piacere che, anche per la versione onDemand, si inizia a vedere il proliferare di nuovi addon e di nuove funzionalità. Non ci resta che attendere i nuovi sviluppi. Una piccola precisazione: Non tutti gli addon che sono stati citati sono a pagamento, ma alcuni di essi sono gratuiti. Questo per sottolineare che non tutti gli addon che sono disponibili per l’onDemand sono necessariamente sempre a pagamento 🙂

Una buona notizia

Una buona notizia da Atlassian. Come annunciato dal loro Blog, Atlassian University è adesso accessibile a tutti. tutti i contenuti soo disponibili a chiunque voglia imparare.

Basta connettersi al link university.atlassian.com per poter usufruire gratuitamente di tutti i contenuti.

Migliaia di Tips, informazioni, articoli sono a disposizione :-). Anche se in inglese, questi articoli sono molto interessanti. Li consiglio a tutti coloro che vogliono imparare, iniziare ad imparare i prodotti della Atlassian o che sono curiosi di capire quali potenzialità può offrire. Buon divertimento 😀

Affrontiamo un argomento abbastanza spinoso. Backup e Restore dei dati di Confluence e JIRA.

Premessa

Almeno una volta nella vita capiterà di dover eseguire il restore. Lo stesso accadrà anche per Confluence e JIRA, che non sono da meno. Il consiglio che dò è di preparavi a tale evento, eseguendo dei test di restore dai backup che sono stati realizzati, cercando di capire bene tutte le operazioni che devono essere eseguite e tutti i problemi che si possono presentare. Al termine delle prove, si disporrà della esperienza per poter eseguire le operazioni necessarie senza grosse difficoltà.

In questo post vedremo alcuni scenari e descriveremo come eseguire il restore dei dati, rischi e punti di attenzione.

Tipologie di backup

Esaminiamo le possibili tipologie di backup che abbiamo a disposizione.

Per tutte le installazioni (onDemand e download) messe a disposizione, possiamo eseguire un backup generale di:

• Confluence – Tutti gli space (pagine, commenti, allegati, etc), comprensivi degli utenti, sono esportati su di un unico file ZIP;
• JIRA – Tutti i progetti e gli allegati, comprensivi degli utenti, sono esportati su di unico file ZIP.

Per Confluence è possibile anche eseguire una esportazione di un singolo Space ed importarlo. Lo stesso può essere eseguito anche su JIRA, con la differenza che è possibile eseguire l’import di un singolo progetto, sempre partendo da un intero backup (Rif. alla seguente risposta su Atlassian Answer).

Per grandi installazioni, su server locali, non è conveniente eseguire delle esportazioni così indicate, in quanto i file XML risultano troppo grandi per essere gestiti. In questo caso occorre fare riferimento alla seguente pagina, dove viene specificato meglio quale strategia utilizzare per i backup e per i ripristini. Di seguito comunque indicheremo come eseguire un restore.

Una considerazione….

I dati presenti sul file ZIP possono variare da versione a versione (sia per Confluence che per JIRA) e non sempre si riesce ad importare da una versione all’altra. E’ possibile operare una workaround, come  riportato nel seguente link, ma nel caso di  evidenti differenze di versioni (es. da una versione 3.5 ad una 5.5), allora conviene procedere all’aggiornamento dei dati attraverso un upgrade del sistema Confluence o JIRA.

Possibili scenari

I principali scenari che vi si possono presentare sono:

• Restore di un sistema installato su di un server locale, sia esso il server di produzione, sia esso il server di test da utilizzare per vari scopi (test di nuovi plugin, ambiente di test per replicare eventuali malfunzionamenti, etc);
• Spostamento dei dati da un confluence ondemand ad una installazione in locale (in questo ultimo caso si vuole portare le informazioni da uno o più space verso una installazione che già contiene degli space e che risulta in uso).

Nel caso del primo scenario, nella ipotesi che si disponga di una installazione della stessa versione del backup, possiamo eseguire il ripristino come segue:

1. Riportare il file di backup su (CONFLUENCE_HOME)/restore oppure posizionarlo su apposita directory dove eseguire il restore delle informazioni. La procedura consente di poter selezionare dove prelevare il file ZIP (vedi figura successiva);
2. Accedendo alla sezione di amministrazione, sezione Import Site, selezionare quindi il file da importare, come mostrato nelle due figure successiva, per Confluence e per JIRA.

CONFLUENCE ADMINISTRATION

JIRA ADMINISTRATION

Qualora sia stata eseguita una strategia di backup differente (come indicato prima, facendo riferimento alla pagina del manuale di confluence), dove si è eseguito:

• Backup del database;
• Backup della Confluence Home (o JIRA Home)

il ripristino deve essere eseguito ripristinando entrambe le due componenti sopra indicate, a server spento. Quindi riattivare il tomcat ed attendere il riavvio, controllando tutti i messaggi che si presentano nel log. Qualora si stia predisponendo una nuova installazione, vuoi di un server di test o di altro, occorre allora modificare i puntamenti al database, presenti nel file confluence.cfg.xml, e inserire dove è stato eseguito le coordinate del database di cui si è eseguito il restore. Questa modalità può essere eseguita solo su installazioni in locale.

 Punti di attenzione

Come ho indicato prima, i file ZIP presentano anche le indicazioni degli utenti. DI conseguenza, quando si esegue il restore, occorre prestare molta attenzione. Se si vuole eseguire un restore di un backup su di una installazione già avviata (vuoi per eseguire una unificazione di sistemi diversi, una on demand ed una locale), quando si esegue una importazione dello ZIP, gli utenti vengono riportati sulla installazione in cui si esegue il restore, rimuovendo il contenuto preesistente. Se non si agisce con criterio, si rischia di fare dei danni.

In questo caso occorre operare degli accorgimenti. Nel caso di JIRA, eseguire una importazione di un singolo progetto (nel caso di più progetti, l’operazione potrebbe richiedere molto tempo: Valutare bene le operazioni in questo caso). Nel caso di Confluence, procedere ad una esportazione di singolo space e relativa importazione.

Collect, service, report

Si tratta di un nuovo Addon per JIRA, che fondamentalmente si occupa di gestire le richieste utenti ed implementare un Service Desk completo, comprensivo della gestione degli SLA in base al tipo di richiesta.

L’addon è disponibile sia nella versione onDemand che nella versione download. L’installazione dell’Addon non richiede particolari competenze, grazie anche al lavoro svolto da Atlassian, che ha reso il lavoro di manutenzione molto semplice.

Una volta installato (Visibile fin da subito nella toolbar in alto), si procede alla configurazione. Quindi si crea un nuovo progetto destinato alla gestione del service desk oppure viene data la possibilità di poter associare tale funzionalità ad un progetto già esistente. A questo punto è possibile definire i vari SLA e definire la reportistica per valutare le performance del servizio.

Fatto ciò, l’addon è a completa disposizione degli utenti, che possono fare subito uso delle nuove funzionalità e impostare le prime richieste.

Attraverso le opzioni del menù sopra riportato, è possibile generare le richieste, che fondamentalmente sono dei task di JIRA, visionabili anche attraverso le normali viste di ISSUE e di progetto.

Utilizzando l’addon, è possibile visionale le code di gestione dei vari task:

Una volta che il task viene assegnato ad un utente, il lavoro di gestione è il medesimo di un task JIRA. L’addon mette a disposizione diverse possibilità di modificare o adeguare le varie code di task, in base alle richieste ed esigenze dell’utente.

Una sezione report, consente di poter visionare l’andamento dei task e valutare la situazione, come mostrato dalla seguente immagine:

A questo punto la fantasia non deve far altro che scatenarsi. Gli utilizzi possono essere molteplici. Si può configurare l’addon per gli usi più svariati:

• Richiesta/Gestione Ferie e permessi
• Richiesta installazione software
• Richiesta supporto su vari sistemi

Nei prossimi post vedremo un uso combinato di JIRA Service Desk con altri addon e sistemi della Atlassian.