In questo post andremo ad esaminare un addon per Jira, che permette di poter eseguire una operazione molto importante: Eseguire un rilascio. 

Giusto per spiegare meglio

Questa operazione, per i prodotti Atlassian, non sempre è possibile. Infatti, come sempre ricordo, molte operazioni sono e rimangono manuali. Di conseguenza, se si dispongono di due ambienti (produzione e test) e vogliamo eseguire un rilascio, normalmente occorre ripetere le configurazioni nella produzione, con alta probabilità di errore. In questo caso abbamo a disposizione un addon che promette di eseguire un allineamento di ambienti 🙂

Presentiamo KIWI (Workflow Importer) Questo addon permette di poter eseguire il deploy del Workflow da una istanza all’altra. Oltre a questo permette di poter esportare anche altre caratteristiche dei Workflow.

Possiamo eseguire Import/Export in maniera molto semplice.

La procedura permette una ottima configurabilità. 

Conclusioni

Abbiamo un addon F A N T A S T I C O. Si tratta di un addon che permette di poter eseguire il deploy. Non vedo l’ora di provarlo.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

In questo post andremo a testare questo addon e vedremo dal vivo questa nuova grafica di Jira Cloud. A tale scopo andremo ad usare le nostre istanze di test cloud.

Installazione

Partiamo come sempre dalla installazione, cercando il nostro addon da installare. Rispetto alle altre installazioni, teniamo presente che sarà più semplice dato che l’addon è ancora in beta ed è free (al momento in cui viene redatto il post, questo è lo stato dell’addon).

Selezioniamo il tasto Install e procediamo ….

Accettiamo le condizioni ….

Configurazione

Proseguiamo con la configurazione che,al momento, non è necessaria: Non abbiamo alcuna configurazione globale 🙂

Passiamo al test

Test

Iniziamo la nostra sessione di test andando a verificare come viene modificata la visualizzazione delle issue. Ci posizioniamo su di una issue qualsiasi:

Notiamo la presenza, in alto a destra, di un tasto FDS Edit, che ci permette di attivare la nuova visualizzazione.  Questo è il risultato:

Per meglio chiarire il funzionamento, ho prepatato questa GIF che ci da un ulteriore aiuto:

Conclusione

UN primo passo ma un primo grande risultato. Abbiamo un addon che ci permette di poter personalizzare la visualizzazione e permette di semplificare anche le informazioni mostrando solo l’essenziale. Il primo giudizio è assolutamente POSITIVO. Attendo i prossimi sviluppi e sono molto sicuro che i prossimi rilasci produrranno dei risultati non indifferenti.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

Dopo lunga attesa è finalmente arrivata la possibilità di poter personalizzare  l’interfaccia grafica di Jira Cloud 🙂

F A N T A S T I C O

Abbiamo quindi la possibilità di poter personalizzare la nostra interfaccia grafica di Jira, attraverso un addon in beta e free (al momento in cui viene redatto il post, l’addon presenta queste caratteristiche)

Conclusioni

Dalle immagini sembra che la personalizzazione sia veramente importante e particolare. Non vedo l’ora di provarla

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

Il seguente video mostra (audio in inglese) come funziona l’addon. 

In questo post andremo a vedere quali sono le novità della nuova versione di Jira 7.12. Andiamo a curiosare 😀

Subito al dunque

Abbiamo un netto miglioramento nella gestione dei campi custom, dove possiamo eseguire uno scanning e verificare quali sono quelli che devono essere configurati

In aggiunta, a pagina di gestione dei campi custom è stata migliorata e resa molto più leggibile

che altro?

Abbiamo anche un miglioramento delle informazioni nella gestione dei filtri, che sono molto importanti.

dove possiamo vedere che abbiamo molte più informazioni relative allo stesso.

Possiamo anche copiare l’indice da un nodo all’altro (per le versioni Data Center) e possiamo anche disabilitare i giorni in colonna (day in column) presenti nella kanban board, oltre ad aver eseguito il fix di diversi bugs, come mostrato nel seguente Release Notes della documentazione.

In questo post cerchiamo di fare un punto della situazione su di un argomento croce e delizia di tutti noi: Le Notification.

Facciamo il punto

Partiamo descrivendo la situazione al momento in cui abbiamo installato il nostro Jira. Quello che abbiamo a disposizione lo riassumiamo come segue:

• Jira mette a disposizione un Notification Scheme di default che impone l’invio di mail di segnalazioni per diversi eventi inerenti le issue. 

• Questo causa un primo email bombing di segnalazioni non indifferente. Nella mia esperienza ho visionato diverse aziende che hanno subito modificato questo schema, al fine di riuscire a ridurre questo bombardamento a dei livelli …. accettabili. L amodifica comporta la generazione di un nuovo Notification Scheme e la relativa associazione ai progetti di interesse. 

• Se si crea un nuovo progetto e si utilizza lo scheme standard, senza andare ad impostare lo schema effettivo, quello che si ottiene è un effetto contrario: Si vuole far si che la mail sia solo una segnalazione, ma se si esagera, si ottiene che gli utenti butterano via le mail alla prima occasione utile, cancellandole nella peggiore delle ipotesi.

Ovviamente non si tratta di tutti i casi, ma di una buona percentuale, che purtroppo causa l’effetto di mettere in giro la nomea che Jira sia uno spammer semi-autorizzato. Conseguenza: molte aziende non vedono i vantaggi di questo prodotto e finiscono per lasciarlo stare.

Cosa possiamo fare?

Partendo dallo schema di Default, quello che possiamo fare è di identificare quelle situazioni in cui serve inviare le mail e le situazioni in cui NON si deve inviare. Possiamo gestire il tutto attraverso le funzionalità che Jira stesso mette a disposizione.

Conviene, come Best Prectice, gestire questa situazione utilizzando i ruoli nei progetti, in modo da riuscire a gestire meglio la la situazione. Mi spiego meglio: 

• I ruoli possono essere utilizzati come dei gruppi ma riguardano molto di più la configurazione dei progetti.
• Possiamo limitare l’invio ad un numero assai più ridotto di persone. 

Alternative?

Abbiamo a disposizione una serie di strumenti che ci possono aiutare nel gestire le notifiche, integrando le funzioni che abbiamo a disposizione o, se vogliamo, sostituendole. Vediamoli in dettaglio cercando di descrivere come possono esserci di aiuto/supporto agli strumenti out-of-the-box.

Notification Assistant for Jira

Grazie a Riada abbiamo a disposizione uno strumento molto interessante, per le nostre istanze Server. Si tratta di un addon che introduce la possibilità di poter inviare delle mail basandosi su JQL. 

Issue type notification schemes

Grazie a Koncis, abbiamo a disposizione uno strumento che estende il notification scheme mettendo a disposizione delle funzionalità aggiuntive. Curiosiamo 🙂

Conclusione

Nei prossimi post cercheremo di fornire delle ulteriori indicazioni per aiutare nella configurazione di Jira.

In questo post andremo ad analizzare un addon che ci permette di poter andare a verificare una cosa molto importante…. Chi ha cancellato le nostre issue.

Ma prima di tutto….

Ringrazio il buon Alejandro Villalobos Vázquez, che mi ha segnalato. Un ringraziamento di cuore.

Subito al dunque

Questo addon ci permette di poter andare a visionare chi ha eseguito delle cancellazioni di issue, sia singola issue, che tramite bulk operation

Attraverso una interfaccia ad hoc, come possiamo vedere di seguito:

possiamo eseguire delle ricerche sulle cancellazioni

con ottimi risultati

Conclusioni

S P E T T A C O L O :-). Non c’è altro modo per definire questo addon. Non vedo l’ora di provarlo 😀

Reference

Maggiori informazioni alla pagina del Marketplace.

In questo post torniamo ad affrontare l’argomento dell’anonimato e della protezione dei dati in Jira, andando ad mostrare il risultato del test di un addon che, da quanto leggiamo, promette bene.

Installazione

Partiamo, come sempre, dalla installazione, andando a cercare il nostro addon direttamente dalla lista degli addon disponibili, come mostrato in figura:

Selezioniamo Free trial, per iniziare il processo di installazione ….

Selezioniamo Accept e attiviamo la procedura di installazione ….

Una volta completata l’installazione, procediamo con la fase di configurazone generale.

Configurazione

Andiamo a vedere le sezioni che l’addon mette a disposizione per configurare, a livello generale, l’addon. La prima cosa che notiamo è l’aggiunta di due nuovi menù nella sezione di gestione Addons:

Se selezionamo Global Configuration, accediamo alla fase di configurazione vera e propria, come mostrato dalle seguenti figure:

In pratica, questa sezione ci propone tutta una serie di campi, tra standard e custom, dove possiamo andare a rendere …. anonimi.

Se selezioniamo la seconda voce di menù, Bulk Anonymize, quello che viene mostrato è la procedura da eseguire, in base alla configurazione impostata, per rendere i campi …. anonimi.

Procediamo con il test

Test

Partiamo con il test e andiamo ad impostare la configurazione di prova, come mostrato in figura. Si tratta di una configurazione che ho impostato in base alla situazione del mio ambiente di test.

Partiamo dalla seguente situazione iniziale:

Andiamo ad attivare la procedura di (coniamo un neologismo) anonimizzazione 😛

IL risultato è il seguente:

Vediamo che sono stati …. anonimizzati i contenuti dei campi presenti nella screen view della nostra issue, del progetto selezionato, ed in più, nella issue anonimizzata, abbiamo la visualizzazione della sezione Zorro Anonymizer, dove sono riportati i campi che sono stati criptati. Per tornare indietro abbiamo riattivato la procedura Bulk e siamo stati in grado di sbloccare i dati e ritornare alla situazione iniziale.

Conclusioni

Questo addon rispetta in tutto e per tutto le aspettative. Gli ambiti di utilizzo sono TANTISSIMI e abbiamo migliaia di idee su come utilizzarlo :). Lo consiglio come addon indispensabile nelle situazioni in cui si debbano condividere delle informazioni …. ma non per tutti 🙂

Reference

Maggiori informazioni sono presenti nella pagina del marketplace.

In questo post andremo a segnalare una funzionalità molto interessante, che risulta molto utile nella realizzazione di documentazione. si tratta dell’addon per Jira PDF View Plugin for Jira (PDF Exporter)

Questo addon, messo a disposizione dalla Midori Global Consulting Kft., permette di poter eseguire diverse tipologie di esportazioni su PDF

Si va dalle issue alle ….. Dashboard. In questo caso la Midori Global Consulting Kft. stessa mette a disposizione un Video di Youtube in cui descrive molto bene come realizzare queste operazioni, che trovate di seguito 🙂

In questo post affrontiamo una piccola digressione su come possiamo eseguire delle personalizzazioni di PORTAL. Cercheremo di analizzare quali possibilità abbiamo a disposizione e che addons possiamo sfruttare per meglio personalizzare il tutto.

Out-of-the-box

Abbiamo già analizzato, nel blog di MrAddon, quali possibilità abbiamo a disposizione, verificando quali possibili opzioni sono già a nostra disposizione, ma queste non sono tutte sufficienti per poter soddisfare tutte le necessità di cui gli utenti abbisognano.

Il confronto l’ho operato con i vari clienti/utenti con cui mi sono interfacciato.

Che altro possiamo fare?

Iniziamo ad analizzare i vari addon, presenti nel Marketplace di Atlassian, al fine di capire che altro possiamo fare per personalizzare PORTAL

Se vogliamo dare una nuova grafica, possiamo utilizzare  Refined Sites for Jira Service Desk

L’esperienza di RefinedWiki, che ha prodotto l’addon per personalizzare il layout di Confluence, di cui abbiamo già abbondantemente parlato in vari articoli in questo blog, permette di poter modificare ed aggiornare la grafica

Possiamo vedere che PORTAL lo possiamo personalizzare parecchio 🙂

Altra personalizzazione che possiamo eseguire è quella di poter accedere anonimamente a PORTAL senza aver bisogno di eseguire alcuna LOGIN. Il tutto attraverso Anonymous Portal for Jira Service Desk

Questo addon permette di poter generare delle segnalazioni attraverso PORTAL senza avere la necessità di doversi loggare. Si tratta di una estensione di un’altra funzionalità, presente in Jira, che andiamo a personalizzare: Issue Collector.

Il seguente Video fornisce (in inglese) un dettaglio maggiore, in attesa che vi inoltri la solita recenzione in Italiano 😀

https://youtu.be/LyUaekZaxtI

Ma torniamo alla possibilità di poter personalizzare l’output di PORTAL. Una delle richieste che maggiormente viene fornita dai clienti è la possibilità di poter visionare, tra le richieste degli utenti, dei campi che normalmente non sono visibili :). In questo caso ci appoggiamo a Ultimate Theming for Jira Service Desk

Abbiamo avuto modo di parlare di questo addon e di testarne le potenzialità. 

Possiamo anche aggiungere delle funzionalità che risolvono anche delle segnalazioni utenti (che come abbiamo già fatto notare, spesso diventano delle forche caudine cui dobbiamo passare con i nostri clienti) che ci obbligano a superare dei problemi che ancora la Atlassian non ha rilasciato.

In questo caso ci viene in aiuto Collective Issue View for Service Desk

Questo addon ci permette di superare JSD-270 e ci permette di dare visibilità, agli utenti di una stessa organizzazione, delle segnalazioni che riguardano la loro organizzazione attraverso PORTAL. 

Per concludere, possiamo andare a gestire meglio i Knowledge base, che PORTAL mette a  disposizione, attraerso un altro addon (messo a disposizione da  //SEIBERT/MEDIA, ovvero lo stesso produttore che mette a disposizione il precedente addon. 

Si tratta di  Service Desk Knowledge Base Custom Field.

Questo addon mette a disposizione un nuovo campo Custom, che permette di poter condividere degli articoli di KB direttamente nelle risposte verso il cliente, dando la possibilità di renderli disponibili non solo nella ricerca standard, ma anche nelle risposte vere verso i clienti 🙂

Conclusione

Abbiamo a disposizione molte possibilità d poter estendere il nostro PORTAL, andando dalla visualizzazione grafica alla aggiunta di nuove funzionalità, le quali spaziano tra diverse possibilità/necessità. Nei prossimi post andremo a verificare gli addon che ancora non abbiamo censito e verificheremo cosa mettono a disposizione testandoli sul campo .

In questo post andremo ad analizzare un aspetto molto interessante. Cercheremo come, attraverso gli strumenti di cui disponiamo, sia stato possibile che lo stato di un Workflow sia cambiato Vediamo come

Esploriamo

La domanda che ci siamo posti non è affatto fuori luogo, ma è la classica domanda che ci si pone quando ci si trova di fronte ad un problema e dobbiamo dare delle risposte certe. Sopratutto quando ci sono di mezzo dei clienti. 

Un valido strumento è sicuramente l’Audit Log di Jira, che ci permette di poter scoprire se degli utenti hanno eseguito diverse operazioni, come possiamo vedere dalle seguenti immagini. 

Workflow modificato

Possiamo risalire alle modifiche di un workflow:

Come possiamo vedere, abbiamo a disposizione un primo strumento non indifferente.

Ottimo, che altro?

Possiamo anche arrivare a vedere altro? Ma larisposta è si. Se andiamo sulla/e issue incriminata/e, possiamo vedere la storia. Ma se aggiungiamo il Jira Suite Utility, abbiamo un ulteriore piccolo aiuto 🙂

Quello che vediamo è l’aggiunta di un TAB nella sezione activity della issue:

dove abbiamo una indicazione particolare del cambio di stato :). Abbastanza utile. In aggiunta abbiamo che Jira si salva tutte le operazoni che eseguiamo (anche se eseguiamo delle BULK, queste salvano informazioni circa quanto eseguito). Di conseguenza, armiamoci di pazienza ed andiamo a spulciare le operazioni per capire che cosa è successo. Di strumenti ne abbiamo.

Se poi citiamo nuovamente il LastLog della DecadisAG, otteniamo anche la possibilità di poter leggere le informazioni del LOG direttamente da Jira

Conclusioni

Possiamo risalire a diverse azioni che sono state commesse su Jira e capire chi ha fatto cosa. Come novelli Sherlock Holmes possiamo trovare le risposte che vogliamo.