In questo post andremo ad esaminare un addon che ci mette a disposizione una funzione interessante. Vediamo in dettaglio addon e funzione.

Le presentazioni

Questo addon ci permette di poter eseguire delle operazioni interessanti, ovvero:

• Permette di definire un template di issue
• Possiamo precompilare titolo e descrizione della issue

A questo punto abbiamo una cosa molto interessante

Dalla precedente immagine possiamo vedere come l’addon permette di definire un template. Ci avete fatto caso? abbiamo lo stesso sistema che abbiamo per creare una issue. Questo significa che non dobbiamo imparare nulla di particolare.

Possiamo definire, nell’ambito dello stesso progetto, una template per issue type. Lo vediamo dalla precedente immagine

Interessante, lo provo subito

Partiamo subito dalla prima operazione. Installiamo l’addon nella nostra istanza. Come sempre vediamo come procedere.

Configurazione Generale

Proseguiamo con la configurazione generale che l’addon. Ci accediamo dal menù principale Apps.

Da li possiamo referenziare i vari template che abbiamo definito. Possiamo anche accedere dalla sezioen Apps presente nelle Project Settings. Faccio una annotazione. Potrebbe darsi, per chi ha installato l’addon quando ancora era gratuito, potreste trovare una immagine come la seguente

Da li andiamo a definrie il template che andremo ad usare. Vediamo come si configura un template

Come possiamo osservare, la creazione di un template non richieste alcuna complessità: Sembra quasi che creiamo una nuova issue. L’assegnazione non è altro che una semplice opzione che andiamo a selezionare.

Proviamo quanto abbiamo configurato

Adesso proviamo il tutto e verifichiamo il risultato.

dalla Gif sopra riportata, vediamo che l’utilizzo è molto semplice e ci permette di poter generare le issue direttamente compilate come abbiamo definito.

Conclusioni

Abbiamo un addon che ci permette di poter generare delle issue pre-compilate come ci servono con pochissima configurazione. Questo addon non risulta molto difficile da usare e permette di poter risolvere alcuni casi di uso che mi sono stati richiesti nel corso della mia vita lavorativa. La prova è stata eseguita con la versione free dell’addon. Nel momento in cui scrivo è disponibile una versione a pagamento che sicuramente presenta delle ulteriori funzionalità.

Reference

Maggoori informazioni sono reperibili dalla pagina del Marketplace.

In questo post affrontiamo un argomento interessante, inerente le Regole di Automazione. Vogliamo creare una schedulazione pianificata tramite le regole di automation per creare una issue/task/compito in base a delle richieste particolari. Vediamo come fare.

Andiamo con ordine

Vogliamo creare in maniera automatica e schedulata una issue particolare ma quando andiamo a richiamare tutti i vari mattoncini lego delle nostre regole, abbiamo dei problemi e siamo in pieno disastro. Come possiamo fare?

Abbiamo una soluzione

Ebbene si: abbiamo una soluzione, ma andiamo sempre con ordine: un passo alla volta. Sappiamo che possiamo impostare un apposito trigger nelle nostre regole di automation, che ci permette di poter gestire le schedulazioni. In particolare (vedi immagini seguenti):

abbiamo quindi tutto, ma abbiamo anche un problema che non possiamo trascurare: Dobbiamo specificare un JQL per selezionare l’elenco delle issue da usare.

Possiamo non specificare il JQL, non sembra obbligatorio. Nel nostro caso di uso vogliamo creare una issue ad un orario ben definito, ma senza dover avere un insieme di issue da gestire. Come possiamo fare? Abbiamo la soluzione e si prega di inoltrare i ringraziamenti alle persone citata nell’articolo di Atlassian Community riportatoi di seguito.

Occorre impostare la seguente condizione

che ci permette di poter gestire questa situazione e ci permette di creare una nuova issue non appena scattato il trigger.

Vediamola in azione

Ho predisposto una regola di prova, per eseguire il test:

Una volta attivata abbiamo il seguente risultato:

e la issue risulta

Conclusione

Abbiamo scoperto un trucco molto importante perché ci permette di creare questa tipologia di schedulazione. questo ci permette di poter avere delle issue create a richiesta senza dover acquistare altri addon e sfruttando lo standard. Ovviamente si tratta di una soluzione che ci fa risparmiare, ma occorre sempre tenere conto di quanto ho già spiegato nel mio post che riguarda la nuova gestione dei limiti di esecuzione delle regole.

Reference

Ringraziamenti a tutti coloro che hanno partecipato alla discussione della Atlassian community e che hanno reso possibile la stesura di questo articolo in Italica lingua.

Credo che sia sempre ottimo precisare e dare ulteriori indicazioni sulle Automation, che sono un mondo molto vasto ed interessante. Cerchiamo di fare una piccola precisazione che sicuramente sarà molto utile.

Nel dettaglio

Quello che abbiamo a trattare riguarda il come generare un task affinché sia collegato ad una Epic. Come sappiamo la Epic è un caso eccezionale tra tutte le issue presenti su Jira. Si tratta dell’unica issue type che permette di poter avere delle Issue figlie. I motivi li abbiamo trattati in altri post precedenti ma credo che a breve li andremo a riprendere. 😉

Se vogliamo introdurre questa informazione quando usiamo le regole di automation ci accorgiamo di una cosa: Usando l’azione di Edit Issue, quando selezioniamo il campo Epic Link, non riusciamo a passare il valore. Qualcosa non funziona.

Il risultato non è quello sperato. Sembra quasi che l’azione non si esegua. Quindi?

Nozioni di Storia di Jira

Dobbiamo sapere (da storico dilettante non posso esimermi) che originariamente non esisteva la gestione Agile su Jira. E’ stata aggiunta da un addon (greenhopper) che ha introdotto questo aspetto. Atlassian si è buttata a pesce ed ha acquisito l’addon. Adesso sembra tutto integrato, ma….. in realtà credo ci sia una separazione ancora netta. Credo che sotto sotto sia rimasto un addon separato e di conseguenza anche il campo sia gestito in maniera separata.

Ho scartabellato e verificato ed il risultato è questo articolo del Community: Il campo va gestito esattamente come un qualsiasi campo custom. Passiamo al Json:

Se usiamo questa indicazione, riusciamo ad arrivare all’obiettivo.

Conclusione

Un ringraziamento a tutti coloro che hanno partecipato a questa discussione che ha permesso la redazione di questo articolo in Italica Lingua.

Un ultimo appunto:

Mentre componevo questo articolo, ho notato una cosa molto carina. Atlassian sta rivedendo l’interfaccia grafica della sezione delle regole di Automation. Infatti:

promette bene. Vedremo nei prossimi mesi che cosa succederà.

In questo post affrontiamo un argomento interessante, inerente le Regole di Automazione. Già recentemente abbiamo parlato, in questo post, di come la gestione dei limiti di queste regole cambiano dal prossimo primo novembre. Vediamo in questo caso come sopperire ad una necessità, ovvero come possiamo aggiungere un link ad una Pagina di Confluence ad una issue, direttamente da Regola di automazione.

Andiamo con ordine

Vogliamo associare ad una issue, quella che ha causato l’esecuzione della nostra regola, una pagina di Confluence ben precisa. Una cosa che notiamo subito è che non abbiamo a disposizione una azione specifica attraverso le Automazioni. DI conseguenza siamo leggermente frustrati. La domanda sorge spontanea. Come possiamo fare??

Abbiamo una soluzione

Ebbene si. Possiamo sfruttare una delle azioni che meglio si adegua per poter agganciare una pagina ad una issue. In particolare possiamo sfruttare questa azione:

Da questa azione possiamo fare ua cosa molto semplice: Chiamare una API di Atlassian e agganciare la pagina alla issue. ma vediamo quale è la API che andiamo a richiamare.

https://yourdomain.atlassian.net/rest/confluenceIssueLink/1/confluence?issueId={{issue.id}}&pageUrl={{createdPage.url}}

Questa è la chiamata alla API che ci interessa

Quello che occorre fare è impostare i parametri che ci servono e successivamente applicarli tramite la regola.

Il risultato è il seguente:

Conclusione

Questo è molto interessante. Possiamo agganciare una pagina Confluence alla nostre issue in maniera veramente semplice. Ci sono degli accorgimenti da tenere presente quando si utilizzano delle API, ma ne parleremo in maniera più approfondita in separata sede. Si tratta di una sorpresa. Rimaniamo in contatto.

Reference

Un ringraziamento a tutti i partecipanti a questa discussione della Atlassian Community, dove è stato chiarito questo punto e che ha permesso di poter scrivere questo articolo in Italica Lingua.

In questo post andremo ad esaminare un addon veramente interessante. Vi posso assicurare che ho avuto la possibilità di eseguire un collaudo molto accurato ed il risultato mi ha lasciato seriamente a bocca aperta dai grandi risultati ottenuti. Ma andiamo con ordine: Partiamo dall’inizio e spieghiamo il caso di uso cercando di mostrare come funziona questo addon.

Il caso di uso che mi si è presentato

In questa situazione, avevo la necessità di dover modificare massivamente il contenuto di un determinato campo, risultato della Migrazione da Server a Cloud per conto di un mio cliente. In questo caso, i campi migrati erano il risultato della migrazione del valore di Elements (ex nFeed). Il problema è che il valore dei campi risultava un qualcosa di questo genere, inaccettabile da proporre al cliente.

{“key:[“XXXXXXXX – Una descrizione del codice”]}

il risultato era un Json che non rispecchia proprio il valore desiderato dal cliente. Le funzionalità standard non permettono delle modifiche così approfondite. Si rendeva necessaria una operazione di ingegno. Iniziavo una analisi alchemica che mi aiutasse nella risoluzione del problema.

…. ma alla fine il risultato è giunto insperato

Una soluzione si è presentata quando oramai sembrava tutto perduto. Un addon mi salvava la vita e mi permetteva di poter correggere il valore e risolvere la questione. Si tratta di Advanced Bulk Edit for Jira, un addon della Codefortynine molto molto interessante.

Questo addon permette di poter eseguire delle operazioni sui campi permettendone la MODIFICA. Questa è una caratteristica molto molto interessante.

Dalla precedente immagine possiamo osservare che abbiamo diverse possibilità per modificare i campi. Possiamo aggiungere dei valori, eseguire delle operazioni di Sostituzione di testo con altro, etc. La faccenda diventa interessante

La mia esperienza lavorativa

Nell’utilizzo di questo addon ho notato una cosa molto molto interessante. Se andiamo ad eseguire una query JQL, quello che otteniamo è il seguente risultato (il particolare sul CLOUD): La query JQL non restituisce più di 1000 risultati, anche se le issue sono più di 1000. Questa è una limitazione che le API di Jira dispongono. DI conseguenza abbiamo sempre qualche problema

La seguente schermata è stata presa (opportunamente trattata per non mostrare dati riservati) al fine di riuscire a mostrare il risultato. Se ci fate caso il numero di issue selezionato è maggiore di 1000.

Quello che si nota è che il limite di 1000 issue è superato con questo addon. Non male, assolutamente non male.

Conclusione

Abbiamo un addon MOOOOOOOLTO MOOOOLTO interessante. Ho già identificato una serie di possibili utilizzi di questo addon in altri casi di uso. Verificherò e vi riporterò di seguito in altri post. Rimaniamo in contatto.

Reference

Maggiori informazioni sono disponibili presso la pagina del Marketplace.

Sono sempre stato leggerissimamente scettico dei progetti Team Managed. In questo articolo provo a spiegare come mai lo sono e perché, sempre secondo la mia modestissima personale opinione, è sempre preferibile creare dei progetti Company Managed. In qualsiasi caso

Le ragioni che porto sempre con me

La prima cosa che indico come difetto di tali progetti è il fatto di avere una configurazione molto molto (in alcuni casi uso anche il termine TERRIBILMENTE) limitata. Questo fa si che sia molto semplice configurare un progetto siffatto. Tuttavia non sempre questo può risultare una arma vincente. Infatti se mettimao a confronto le due possibili configurazioni che abbiamo

La prima cosa che notiamo è che le opzioni sono limitate per i Team Managed. I Company managed, per quanto più complicati, sono sempre più completi nella configurazione e nella gestione. Questo sicuramente ci aiuta (per citare un vecchio adagio che ho imparato nella meravigliosa città di Lucca: Nel più c’è il meno).

In aggiunta, nei Team managed ho notato una cosa molto grave (secondo sempre il mio modesto parere): Non possiamo usare le risorse condivise. In alcuni casi mi sono trovato costretto ad una trasformazione di un progetto da TEAM a COMPANY perché non c’era alcuna possibilità di poter espandere tali progetti e sopratutto gli utenti erano stati costretti a replicare all’infinito (copiando manualmente e non assegnando una configurazione preesistente).

In aggiunta, non sempre gli addon sono usabili anche su tali progetti. Ho rilevato che alcuni di essi non rispondono correttamente quando si prova ad applicarli.

Il mio dubbio è che questa tipologia di progetti, per quanto comodi, semplici e rapidi, non presentino delle strutture condivise e standard. Di conseguenza, occorre un qualcosa ad hoc per poter loro agganciare delle funzionalità standard.

Un progetto Company Managed, per quanto sia complicato, hai comunque il controllo completo della configurazione e riesci sempre a cadere in piedi. Mi permetto di condividere un meme che ho visto qualche tempo fà ed esprime esattamente dei concetti molto importanti:

In questo caso è come disporre di un Linux e della sua splendida POTENZA.

Conclusioni

Quello che continuerò a suggerire, consigliare, fare presente e ribadire sotto tutti i punti di vista è che un progetto Team Managed va bene per fare cose molto semplici. Se si prevede nel futuro di fare qualcosa di più, partite subito con un progetto Company Managed.

A tale proposito, vi chiedo di visionare questo video di Monika Rani, che spiega in maniera molto chiara e semplice la differenza tra i due tipi di progetti:

e questo ottimo articolo, sempre scritto da Monika Rani, che spiega come migrare da Team a Company

Migrate team-managed projects to company-managed projects in the Jira Cloud

La gestione degli utenti è molto importante per i Site Administrator dei prodotti Atlassian. Lo sappiamo bene noi che ci lavoriamo tutti i giorni e che ci scontriamo con le varie problematiche.

Tuttavia i produttori di Addon ci aiutano in questo arduo compito. Grazie a loro riusciamo a risolvere al meglio tutte le nostre problematiche, arrivando ad avere

Cosa ci permette di fare?

Questo addon ci aiuta nella gestione utenti semplificata, permettendo anche di poter gestire alcune funzioni interessanti. Andiamo subito a curiosare sulle possibilità offerte.

Possiamo avere una gestione semplificata degli utenti attraverso una funzione di importazione degli stessi e permetterci di semplificarci la vita. Infatti, non tutte le organizzazioni si possono permettere di acquistare Access e l’utilizzo di Addon che dispongono di questa funzione, ci permette di poter avere delle funzioni non indifferenti

IN aggiunta abbiamo la possibilità di poter inserire, sempre in maniera semplice, i nostri customer interni in maniera semplice e veloce, sfruttando le funzionalità che sono presenti a sistema.

La mia esperienza lavorativa

Posso dire che questo addon, in un particolare caso, ci ha permesso di poter gestire al meglio i customer interni di una azienda, permettendoci di poterli creare e configurare in pochissimo tempo (neanche 1 ora).

Abbiamo usato con successo la funzione che ci permette di poter attivare tali customer velocemente ed il cliente è rimasto piacevolmente soddisfatto del risultato. Lui stesso lo utilizza per poter attivare i nuovi customer.

Questa immagine non può che esprimere al meglio quanto penso dell’addon

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

Scrivo questo articolo quasi di getto e per rispondere alle ultime novità sul mondo delle Automazioni. Principalmente sulla parte Cloud di Jira. L’obiettivo è di fornire un quadro situazione per mostrare il funzionamento delle ultime novità e per indicare anche come poterle gestire correttamente. A tale proposito ho predisposto una regola di tipo didattico per descrivere meglio il funzionamento, ma andiamo con ordine.

Marzo 2023

Verso la fine del mese di marzo 2023 succedeva una cosa leggermente strana. Mi segnalavano che nelle istanze Cloud l’addon delle Automation risultava in TRIAL e sopratutto era ben staccato. Di conseguenza molti miei clienti si sono preoccupati (ma non solo loro).

Da un rapido controllo era emerso che Atlassian stava semplicemente integrando l’addon trasformandolo da addon esterno a addon di Sistema.

Infatti se andate a controllare, oggi lo troviamo come addon di sistema.

Fino a questo non ci sarebbe molto altro da dire… tuttavia abbiamo anche delle altre sorprese. L’integrazione si è portata dietro anche delle novità. Vediamole nel dettaglio:

Automation manuali

Una delle novità riguarda l’introduzione delle Automation manuali, ovvero richiamabili su richiesta dall’utente

Notiamo tuttavia una cosa molto molto … preoccupante. La combo che permette di richiamare questa nuova funzione è vicinissima alla combo del passaggio di stato. Molti mi hanno fatto notare (e sono perfettamente d’accordo) che la probabilità di selezionare la combo sbagliata è altissima. Devo riconoscere che la Atlassian ha introdotto una funzione importante, ma tempo che nella foga del momento non abbia ben calcolato dove inserire tale funzione, scegliendo una posizione infelice. Il mio suggerimento è di trattarla come le funzioni degli addon. Esiste la sezione dedicata alle Automation. Credo che sia meglio inserirla li

Non sono d’accordo con il messaggio. A mio giudizio questa sezione è quella ideale per gestire tale funzionalità.

Che altro?

Ci sono anche delle altre novità. Abbiamo a disposizione, sempre lato Automazioni, delle nuove funzionalità interne che ci permettono di poter gestire meglio delle …….. TABELLE DI LOOKUP

Vedo che ho catturato la vostra attenzione. Andiamo subito al sodo. Se infatti ricerchiamo tra le possibili azioni, abbiamo la possibilità di poter creare questa tabella:

Siamo ancora alle prime armi, ma possiamo subito vedere che il potenziale ci sta tutto. Anche se limitato a 20 entry massimo, possiamo impostare una serie di corrispondenze che possiamo sfruttare a nostro vantaggio.

Per richiamare le corrispondenze abbiamo a disposizione un semplice metodo. Infatti questa tabella si definisce come uno Smart Value. Basta semplicemente usare:

{{Esempio.get(issue.summary)}}

per richiamare la corrispondenza. In questo esempio abbiamo la possibilità di poter sfruttare anche degli altri Smart Value. Cosa molto importante.

Risultato, Conclusioni?

Semplice: Abbiamo la possibilità di poter gestire queste regole in maniera molto più semplice, ci liberiamo dalla schiavitù di blocchi IF-THEN-ELSE potenzialmente infiniti e abbastanza difficili da gestire. Ci permette di dare un ordine non indifferente e, come vediamo, anche di gestire al meglio queste situazioni. Ripeto. Siamo alle prime armi. Le novità non sono sempre cattive, ma hanno sempre del potenziale. Dobbiamo sempre vedere il potenziale, senza mai perdere di vista i punti di attenzione.

Un annoso problema che ci assilla è causato dal fatto che non sempre possiamo collegare Jira Cloud con i Database….. fino ad ora. Qualche mese fa stavo eseguendo delle sperimentazioni che mi hanno portato a scoprire un addon molto interessante. Adesso, dopo la sperimentazione posso descrivere i primi risultati.

Descriviamo lo scenario

Questa situazione la conosciamo bene. Quando i clienti ci chiamando perché vogliono leggere le informaizoni dai loro database locali e le vogliono rendere reperibili anche su Jira Clòoud. Questa di solito è la nostra faccia

Proviamo a chiarire. Sappiamo beniussimo che il nostro Cloud è una macchina remota AWS localizzata, nel nostro caso, a Dublino o Francoforte (quindi GDPR RISPETTATA. CHIARO??). Concetto da tenere sempre presente è che Jira Cloud è su Internet e di conseguenza per poter accedere ad un database, questa macchina su internet deve essere (UDITE UDITE) autorizzata.

Ora, se andiamo in una azienda qualsiasi, i responsabili della sicurezza avrebbero qualcosa da dire. Se apriamo una porta del genere, occorre ben presidiarla oppure si rischia di fare dei danni. Ricordiamoci sempre che quando si apre una porta su internet, prima o poi si rischia che qualcuno di non desiderato entri dentro senza il nostro permesso. Fa parte dei rischi.

Quali precauzioni?

Possiamo prendere diverse precauzioni per far si che chiunque tenti di entrare non possa andare oltre un certo limite e, se anche dovesse arrivare, li si fermi. Parafrasando il celebre film “Il Codice da Vinci”, mi permetto di citare un verso della Bibbia: (Giobbe 38-11). e dissi: `Fin qui tu giungerai, e non oltre; qui si fermerà l’orgoglio de’ tuoi flutti?’

Possiamo fare in modo che il database che colleghiamo a Jira Cloud sia una copia con pochi dati. In questo modo, anche se qualcuno dovesse arrivare a leggerli, le informazioni siano parziali e non servibili allo scopo. Questo però implica che:

• i dati devono essere aggiornati a cadenze regolari
• In alcuni istanti i dati non saranno perfettamente disponibili (intendo gli ultimi)
• In ogni caso se qualcuno arriva li, legge dei dati e potrebbe comunque tentare delle operazioni di ricostruzioni.

Sicuramente questo è un sistema per limitare il danno, ma non eliminiamo completamente la possibilità di eliminare il danno.

La vera precauzione consiste nell’inserire il database direttamente su Jira, o sulla macchina remota. Solo così avremmo a disposizione la possibilità di poter gestire una sicurezza molto alta. Se il database è già interno a Jira, allora abbiamo la sicurezza di Atlassian che ci protegge. Tuttavia la macchina remota NON è usabile da parte nostra e non credo che Atlassian ci permetta di poter mettere mano a tali macchine dall’oggi al domani. Di conseguenza le possibilità sono molto ridotte….. oppure no?

Non disperiamo. Abbiamo una soluzione

Ebbene si. Abbiamo una soluzione. Possiamo portare i dati direttamente su Jira e usarli come un database e per questo obiettivo un potente addon ci permette di poter gestire questa situazione. ma come?

Semplice. Possiamo memorizzare i dati all’interno di un progetto di comodo, dove i record sono presenti nelle issue. Come ben sapete, le issue possono diventare qualsiasi cosa noi vogliamo. Questa è una delle grandi possibilità che Jira mette a disposizione di noi utenti.

Benissimo. Se mappiamo i record usando le issue type seguendo questa logica: è un tipo di record. Nell’issue type andiamo a memorizzare i dati che ci servono, utilizzando i campi custom per memorizzare anche altre informazioni del nostro record. Risultato? abbiamo il nostro database locale.

A questo punto passiamo alla seconda domanda. Come lo usiamo?

Anche qui ci viene incontro uno splendido addon che ci aiuta a rispondere a questa seconda domanda. Si tratta di:

Questo addon permette di poter eseguire delle interrogazioni direttamente su Jira come se fosse un database. In questo caso abbiamo a disposizione la nostra arma segreta: il JQL; che ci aiuta nell’interrogare i dati senza grandi problemi. Lo stesso lo possiamo fare con questo addon che ci permette di poter gestire il risultato finale.

L’addon permette di poter creare una connessione a Jira Cloud stesso . Questo consente di gestire Jira Cloud come un database e, come sempre sostengo da immemore tempo, il JQL ci aiuta a creare la query di selezione dei dati

Moooolto interessante e quale è il risultato?

Il risultato finale è che abbiamo a disposizione la possibilità di definire dei campi ‘database’, se mi si può concedere la libertà di scrivere così, dove i valori visualizzati sono prelevati dal progetto che abbiamo definito su Jira

Sfruttando l’addon possiamo ottenere questo risultato:

Come possiamo vedere, l’addon ci permette di poter sfruttare le issue di un progetto come se si trattasse dei record del nostro simil-quasi-database (concedetemi questo termine), ma l’utente finale non vede questa cosa: per lui è una lista. L’addon permette anche di poter aggiornare il campo a cadsenze regolari. Ciò che si deve fare e aggiornare l’elenco delle issue del progetto che abbiamo battezzato. L’addon può essere programmato per far si che l’elenco sia aggiornato a cadenza regolare.

Ovviamente consiglio di trovare un compromesso al tempo di aggiornamento che vogliamo: Questo per evitare comunque di sovraccaricare la nostra istanza di Jira Cloud.

Risultato?

Abbiamo una nuova arma in più per definire un database all’interno di Jira e sopratutto abbiamo la possibilità di poter mantenere una discreta sicurezza senza aprire quella della nostra sicurezza. In aggiunta, questo sistema può essere usato anche per:

• definire assets aziendali senza avere insight
• definire delle tabelle di un database interno a Jira
• definire delle semplici liste valori aggiornabili facilmente
• definire quello che vogliamo all’interno di Jira.

L’unico limite è la nostra fantasia.

Un mio appunto personale

Il 29 Giugno ho avuto il piacere di presentare questa soluzione al Meetup Madrid/Buenos Aires. Mi permetto di condividere il Video del mio intervento, disponibile su Linkedin

Reference

Maggiori informazioni sull’addon sono disponibili nella pagina del marketplace.

In questo post andremo a descrivere i nostri test sulle App che Appsvio ci mette a disposizione. Li ho visti in azione e ho partecipato all’ACE di Boston, dove ho avuto il piacere di fare uno Speech. Li ho testati sul campo su situazioni reali e cercherò, in questa sede, di descrivere gli scenari che ho affrontato.

Customer and Organization Management for JSM

E’ il primo addon che ho avuto modo di vedere in azione e le mie impressioni sono più che positive. Lo scenario che ho visto riguarda la gestione degli utenti esterni di un Service desk. Il mio obiettivo era quello di creare rapidamente e, sopratutto, in maniera molto semplice, un insieme cospicuo di customer. ribadisco. ESTERNI.

Se il cliente deve gestire tale situazione, usando la gestione standard, dette out-of-the-box, abbiamo una sola alternativa: FARLO A MANO.

L’addon ci permette di poter gestire questa operazione in modo più agevole. Una interfaccia non indifferente ci aiuta ad eseguire questa operazione

L’ultima immagine svela come ho fatto. Questo addon mette a disposizione una funzione per poter importare, usando un semplice CSV file, gli utenti che ci servono. Usando questo barbatrucco, possiamo creare tutti i customer esterni che ci servono.

Non ho mica finito

Il test continua nel prossimo post e vedremo che cosa ci permette di fare il prossimo addon Appsvio. Stay Tuned.