JIRA CORE – Prova su strada 2

JIRA CORE – proseguiamo la prova su strada

In questo post andremo a proseguire la prova su strada. Passiamo a visionare l’installazione web.

Dove eravamo rimasti

Eravamo rimasti alla pagina iniziale della installazione web, come mostrato nella seguente immagine:

JIRACORE-06

A questo punto, possiamo scegliere due possibili opzioni:

  • La prima consiste nel lasciare al setup di fare tutto, fornendo solo alcuni semplici parametri e le indicazioni per staccare la licenza.
  • La seconda consiste nel installare manualmente (opzione che andremo a scegliere ūüôā )

Il motivo della scelta √® che in questo post voglio spiegare alcuni punti e, se lasciamo l’installazione fare tutto, allora non riesco a mostrarle ūüėÄ

Una piccola precisazione

Prima di procedere, abbiamo installato il driver MySQL sul JIRA al termine della installazione.Prima di procedere si è reso necessario un riavvio del servizio. Tutte le istruzioni sono presenti in questa pagina della documentazione di JIRA. Occorre riportare nella <JIRA_HOME>/libs il driver.

Una volta installato, per eseguire il restart del servizio, collegandosi come root, eseguire i comandi stop-jira.sh e start-jira.sh presenti nella <JIRA_HOME>/bin. Se non viene fatto, il driver non sarà disponibile.

Quindi procedere con la creazione del database vero e proprio, usando i seguenti comandi:

  • CREATE USER ‘<USERNAME>’@'<JIRA_SERVER_HOSTNAME>’ IDENTIFIED BY ‘<PASSWORD>’;
  • CREATE DATABASE jiradb CHARACTER SET utf8 COLLATE utf8_bin;
  • GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on <JIRADB>.* TO ‘<USERNAME>’@'<JIRA_SERVER_HOSTNAME>’ IDENTIFIED BY ‘<PASSWORD>’;
    flush privileges;

come potete vedere nella pagina che ho indicato prima :-).

Proseguiamo

Andiamo quindi avanti con il setup. Il primo passo che viene richiesto è quello di scegliere il database. Come abbiamo già scritto, scegliamo MySQL e forniamo tutti i parametri per la connessione.

jiracore-02-04

La pagina ci consente di poter eseguire il test di configurazione, verificando se abbiamo inserito tutti i parametri corretti. Quindi procediamo con la fase di installazione, dove sar√† creata l’intera struttura di tutte le tabelle. Questa operazione richiede del tempo. Lasciamo che lavori senza alcuna fretta e attendiamo che si concluda¬†:-).

Al termine, ci sarà proposta la fase successiva, come mostrato dalla figura successiva:

JIRACORE-02-05

Son richiesti i seguenti parametri:

  • Il titolo del JIRA CORE: viene richiesto che titolo mostrare quando accediamo al nostro JIRA;
  • Modalit√† di accesso:
    • Pubblico: Gli utenti si possono registrare in autonomia
    • Privato: Solo gli amministratori possono creare nuovi utenti
  • Definire la Base Url. Si tratta della URL di base che sar√† utilizzata per la gestione del nostro JIRA.

Nella fase successiva viene richiesta la Licence Key. Possiamo, in automagico, ricavarla usando il link generate a JIRA Trial licence, come mostrato dalla figura successiva:

JIRACODE-02-06

che ci reindirizza al portale my.atlassian.com:

JIRACORE-02-07

attraverso il quale ricavare subito, sfruttando le nostre credenziali, la licenza di uso:

JIRACORE-02-08

e quindi riportarla subita nel nostro server e procedere nelle ultime fasi di installazione.

JIRACORE-02-09

Si passa quindi alla generazione della utenza di amministrazione, molto importante. Si tratta di una utenza attraverso la quale riusciremo ad eseguire l’amministrazione dell’intero JIRA. Come mostrato dalla seguente immagine:

JIRACORE-02-10

specifichiamo tutti i parametri e andiamo a generare la nostra utenza.

JIRAVPRE-02-13

Viene quindi chiesto di specificare un avatar. Questo rimarca molto l’aspetto social di JIRA e dei prodotti Atlassian. Come potete vedere, viene specificato l’avatar dell’utente del portale my.atlassian.com.

Quindi, viene richiesto di settare i parametri per gestire la notifica delle email.

JIRACORE-02-11

Come possiamo vedere dalla immagine, vediamo che viene suggerito di eseguire dopo questa operazione. Suggerisco di eseguirla in una fase successiva. Quindi passiamo a settare il linguaggio che sarà utilizzato su JIRA, come mostrato nella seguente immagine.

JIRACORE-02-12

Eseguita tale selezione, l’installazione √® formalmente terminata e si passa ad una fase di¬†quick tour del prodotto, dove sono spiegate alcune informazioni. Salteremo queste e procederemo oltre.

JIRACORE-02-14

Fatto ci√≤, possiamo subito iniziare. Dato che si tratta della prima installazione, viene proposto di creare il primo progetto. Anche in questo caso, possiamo eseguire l’operazione in una fase successiva, come mostrato nella seguente immagine:
JIRACORE-02-15

Fatto ciò, abbiamo la nostra installazione di JIRA. La Dashboard viene proposta e possiamo iniziare nelle fasi successive:

JIRACORE-02-16

Conclusioni

Terminiamo qui questo post, chiudendo l’installazione. Proseguiremo nel prossimo post con la prova su strada, verificando le funzionalit√†, confrontandole con le precedenti versioni e cercando di capire come si comporta questa nuova versione 7 ūüôā

Advertisements

Semplici statistiche in Confluence

Visualizziamo numeri

In questo post sarà mostrato come poter utilizzare Confluence per realizzare delle semplici statistiche. Si tratta di un semplice esempio di uso dedicato alla realizzazione di dashboard, che possono sempre aiutarci nel nostro lavoro.

Di cosa abbiamo bisogno?

Quello di cui abbiamo bisogno è:

  • Confluence (versione cloud)
  • SQL Play
  • Database MySql, per fare tutte le prove di cui abbiamo bisogno. Per tutte le nostre prove, utilizzeremo db4free, un sito che gratuitamente mette a disposizione database mysql di test, attraverso eseguire dei test.

Andiamo in dettaglio

In questo post andremo a vedere un semplice esempio di come visualizzare alcune informazioni. IN questo caso supponiamo di andare a visualizzare delle semplici statistiche sui miei consumi di benzina ūüôā

A tale scopo, ho creato un semplice DB su db4free, dove ho riportato alcuni semplici dati.

Dash00

Sfruttando le potenzialit√† dell’addon SQL Play, ho creato il contesto verso tale database, quindi ho creato la query per visualizzare i dati.

Dash01

A questo punto creiamo la pagina di prova ūüôā

sql10
Ovviamente si tratta di dati di esempio. ūüôā

Conclusioni

Abbiamo visto come inserire delle semplici statistiche da un database remoto. Possiamo a questo punto creare delle dashboard che, leggendo le informazioni da un db remoto, visualizzano i risultati direttamente sulle pagine di Confluence.

 

Panoramica sulle tabelle di Confluence – 2

Il viaggio continua

Continuiamo in questo post quanto iniziato nel precedente, dove abbiamo iniziato a esplorare l’oscuro arcano delle tabelle di Confluence. Andiamo avanti ed iniziamo ad entrare meglio nelle varie tabelle.

Prendendo spunto dal data model di Confluence, andiamo ad esaminare alcune delle tabelle dello schema.

 

Autenticazione ed utenti

Per gestire l’autenticazione, sono utilizzate le seguenti tabelle:

  • cwd_user
  • cwd_group
  • cwd_membership

Mappano rispettivamente gli utenti e i gruppi di appartenenza. La tabella cwd_membership fornisce l’associazione tra utenti e gruppi. . Qualora Confluence sia collegato ad un LDAP, le informazioni in queste tabelle sono aggiornate costantemente e la gestione della password viene affidata al sistema LDAP. Abbiamo visto un esempio di come andare a referenziare queste tabelle su questo post.

 

Spaces

Le informazioni sugli space sono relegate alla omonima tabella Space. Questa viene referenziata¬†anche sulle altre tabelle, per indicare l’appartenenza dei contenuti.

 

Contenuti

I contenuti sono riportati nelle seguenti tabelle:

  • Content –¬†Referenzia diverse informazioni, distinte in base al campo¬†CONTENTTYPE. In particolare, in questa tabella sono presenti sia le informazioni delle varie pagine, che metadati dell’utente e degli space. Nel caso delle pagine, sono presenti TUTTE le versioni della pagina. Attraverso questa tabella Confluence riesce a fornire le differenze tra pagine.
  • Bodycontent –¬†Referenzia il contenuto delle pagine. Queste sono riportati con i vari TAG usati per definirire formati ed altro.
  • Content_label – Referenzia le etichette che sono agganciati ai vari contenuti, distinti in base al campo LABELABLETYPE.¬†

Permissions

Le permission sono sparse su diverse tabelle:

  • Spacepermissions –¬†Referenzia le permission che sono state assegnate ad uno specifico SPACE. Sono riportate sia le permission assegnate a GRUPPI che a singoli utenti. Nel caso dei singoli utenti, prestare attenzione a come sono codificati gli utenti stessi. Fare rifermento al precedente post¬†per vedere come referenziare correttamente il tutto
  • Content_perm_set –¬†Referenzia¬†quale¬†pagina dispone di una restrizione. Il dettaglio √® riportato nella tabella successiva.
  • Content_perm – Da il dettaglio delle restrizioni della pagina referenziata nella tabella precedente, indicando quali utenti/gruppi sono soggetti alla restrizione.

 

Attachments

Gli attachments sono gestiti attraverso queste tabelle

  • attachments –¬†Referenzia i metadati che sono agganciati ai dati.
  • attachmentdata –¬†Referenzia gli allegati veri e propri, nel caso in cui la configurazione di Confluence preveda che gli allegati siano riportati su DB e non su File System.

Conclusioni

In questo post viene mostrato come sono organizzati i dati. Nei prossimi post cercheremo di fornire una ulteriore spiegazione di come sono collegate le informazioni e di come referenziarle.

 

Breve panoramica sulle tabelle di JIRA

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:

profile01

 

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-Jira\WEBINF\Classes\Avatar

Supponiamo di utilizzare sempre l’icona del pinguino ūüôā

pinguino48

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

avatar-new

Dalla tabella cwd_user, identifichiamo l’utente in questione:

user

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’:

avatar-user

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

new-avatar

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

nuovo-profilo

 

 

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>\data\avatars

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.

 

Accedere ai dati di CONFLUENCE

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).

 

profile

 

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:

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

query01

 

query02

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>\confluence\images\icons\profilepic

supponiamo di chiamarla Demoprofile e di memorizzare il seguente avatar:

pinguino48

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

 profiloMod

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.