Questa è una vecchia versione del documento!


Dashboard Set Configurabili

Con il nome Dashboard Set Configurabili si indica l'insieme del nuovo sistema di configurabilità dei menu con cui vengono presentate le dashboard per ogni funzione utente, introdotto dalla versione 4.7.3, che comprende:

  • sistema di classi di gestione
  • nuove funzioni dedicate al SM e all'utente GW ADMIN
  • nuovo tipo di menu di terzo livello

Precedentemente a questo viluppo, la struttura di menu distribuita su tre livelli, era configurata fissa ed immutabile nell’xml di gwProject. Questa operazione era effettuata esclusivamente da utenti configuratori nella fase di implementazione del progetto (App). Le informazioni relative sistema di menu sui tre livelli erano quindi salvate esclusivamente sullo schema dei metadati, la cui gestione è attualmente quasi esclusivamente relegata al webadmin. In generale era quindi molto complicato far modificare informazioni presenti nello schema dei metadati da UI che fossero fruibili dall’utente finale nel webclient. Era quindi estremamente complicato realizzare, con pura configurazione, meccanismi che permettessero all’utente finale, il Solution Manager in particolare, di modificare puntualmente le configurazioni dei metadati. Andando più nello specifico, la problematica si verificava nelle varie funzioni che presentano dashboard in apertura, veniva infatti aperta subito solo la prima dashboard configurata per il prodotto, che era quindi fissa per tutti. Le altre dashboard erano comunque disponibili sotto, come ulteriori leafItem, altrettanto fisse. L’unico margine di dinamicità che preesistente, era legato ai permessi legati alle risorse collegate ai leafItem che, in caso di mancanza degli stessi, faceva sì che i leafItem senza permessi potessero essere nascosti/disabilitati. Di fatto però questo meccanismo è quasi del tutto inutilizzato nelle recenti implementazioni delle linee di prodotto, in quanto si tende a fare funzioni dedicate per ruoli dedicati, molto specializzate, e non più un unico progetto flessibile che varia in base ai permessi dell’utente corrente. Alla luce di tutto ciò a richiesta generatasi è stata quella di, sempre rimanendo nell’ambito e nei confini di prodotto, lasciare all’utente dei margini di personalizzazione. La mancanza di tale funzionalità aveva infatti dei risvolti importanti sul lato commerciale. Nasceva quindi la necessità di colmare una lacuna difficilmente giustificabile nei confronti del cliente. Andava in sintesi creato un nuovo meccanismo che superasse le rigidità imposte dal sistema di menu di terzo livello, che essendo persistito sui metadati, non era facilmente configurabile per soddisfare i nuovi requisiti di personalizzazione delle dashboard

  • Dashboard: in questo contesto sarà spesso usato non tanto per descrivere la scheda dashboard, ma per far riferimento all’entità che modella la singola voce di menu dalla quale effettivamente si apre la relativa scheda dashboard.
  • Dashboard set: raggruppamento di Dashboard, nell’accezione di cui sopra
  • gwDashboardSet: nuovo leafItem di terzo livello, parte del rilascio, volto a dare rappresentazione grafica ad un Dashboard set, dentro una data Funzione
  • Utente Solution Manager (SM): figura a cui è abilitata la possibilità di eseguire personalizzazioni sul sistema di dashboard per Funzione che, fra l’altro, sceglie la dashboard principale per funzione, determina l’ordine delle dashboard secondarie, nasconde alcune dashboard rispetto alla lista del prodotto, cambia i titoli delle dashboard.
  • Utente GW ADMIN: figura a cui è demandata la completa gestione del sistema di dashboard per Funzione. Fa tutto quello che può fare il SM, ed molto altro.
  • Funzione di destinazione: è una Funzione, sulla quale hanno i permessi tutti i soggetti (Utenti finali) abilitati a fruire di un determinato set di dashboard tramite l’apposita menu di terzo livello di tipo gwDashboardSet
  • Funzione dedicata al SM: è una Funzione, creata appositamente per il SM per la personalizzazione dei Dashboard Set per Funzione
  • Funzione dedicata al GW_ADMIN: è una Funzione, del tutto simile a quella dedicata al SM, ma con più funzionalità

Questo rilascio, durante lo sviluppo, ha tenuto conto di questi requisiti:

  • le personalizzazioni sulle dashboard devono essere esposte al Solution Manager (SM), in una funzione dedicata
  • la scelta del SM deve essere fatta fra una lista di dashboard (di prodotto) predeterminate per ogni funzione dall’utente GW ADMIN (in altra funzione dedicata)
  • il SM configura quale dashboard sia la predefinita, cioè la prima ad essere visualizzata, in base alla funzione.
  • il SM può configurare l’ordine di comparsa nel menu delle altre dashboard
  • il SM può nascondere delle dashboard per certe funzioni (gwaFunction)
  • il SM può modificare la label delle dashboard, che comparirà sia come label del menu di terzo livello, sia come titolo del tab ospitante la dashboard.
  • nella funzione di destinazione:
    • la forma grafica per il 3rd level menu gwDashboardSet (complesso della dashboard principale e delle secondarie) deve essere resa tramite un menu di terzo livello. Questo allo scopo di integrarsi con altri menu di terzo livello dentro lo stesso menu di secondo livello.
    • la dashboard principale va tematizzata come un classico leafItem
    • le dashboard secondarie vanno stilizzate differentemente (ma senza calcare con la grafica alcun concetto gerarchico, essendo entità comunque omogenee)
    • le altre dashboard non predefinite, nella funzione di competenza, devono comunque essere fruibili a richiesta, nelle solite modalità (click che apre scheda)
    • va prevista la possibilità, tramite UI, di collassare/espandere in blocco tutte le voci di menu delle dashboard secondarie

E’ stata predisposta una nuova funzione (gwProjectName: dashboard_management), che abilita al Solution Manager la personalizzazione delle varie dashboard, secondo le logiche sopra esposte. In particolare viene presentata una lista dei dashboard set, uno per ogni Funzione.

Nell'ambiente di test è stato predisposto un gwProject prototipo, dal quale è possibile vedere in azione tutti i componenti di seguito descritti.

Report Esportabili (tester/Tester0@)

webadmin (adminTester/admin)

In un'unico gwProject è presente sia la scheda cruscotto per la Funzione utente di destinazione (nel primo menubarItem, primo accordion) sia la scheda di configurazione layout dedicata al Solution Manager e altre anagrafiche di gestione (nel secondo menubarItem, primo e secondo accordion: gli altri accordion sono per debug e dovrebbero essere nascosti durante l'implementazione).

Si rimanda alla pagina dedicata Report Esportabili - Messa in esercizio

Si rimanda alla pagina dedicata Report Esportabili - Gestione Aggiornamenti

Cruscotto Report utente finale (Funzione di destinazione)

Il cruscotto è predisposto per una specifica Funzione di destinazione nell'apposita Scheda di gestione layout dedicata al Solution Manager. Il SM, configurando il cruscotto per una specifica Funzione di fatto controlla i permessi di visualizzazione delle singole Report coinvolte. Affinchè il cruscotto sia visibile deve anche essere configurato lo specifico leafItem nell'xml di Progetto relativo alla Funzione. Esso presenta le varie Report, una per riga, organizzate in Categorie Report. Ogni Report presenta il nome, la descrizione e delle opzioni per essere lanciata. Ogni Report può essere lanciata direttamente nei formati abilitati dal SM (.XLSX, .PDF, .DOCX), utilizzando il modello di default.

Inoltre tramite il button '…' (more options) è possibile aprire un menu che permette di scegliere sia il formato che il modello (fra quelli abilitati).

Se nel file .jasper sono stati configurati dei parametri con il flag 'prompt to user', geoweb provvederà a richiederli all'utente con un floatingPane modale, rispettando il tipo di dato dichiarato nel .jasper. Tipi di dato ammessi:

  • string
  • integer
  • numeric
  • date
  • boolean

Al click su fatto la Report verrà generata tenendo conto degli input forniti:

leafItem XML

La scheda è integrabile nel layout del gwProject come 3rd level menu, usando questo leafItem senza parametri:

<leafItem name="gwExportableReport" label="Scheda Exportable Report (Funzione corrente)" image="eyJjc3NDbGFzcyI6ImZhLXNvbGlkIGZhLWZpbGUtZXhwb3J0Iiwid2lkdGgiOiIzMnB4IiwiaGVpZ2h0IjoiMzJweCIsImNvbG9yIjoiIzAwN0FDMiJ9" type="gwExportableReport" escapeLabel="true" disabled="false" hidden="false">
</leafItem>

API javascript

Codice equivalente per aprire questa scheda.

var title = '';
var params = {};
var tab = openGwExportableReportTab(params, title);

Le report .pdf vengono aperte su un floatingPane con il visualizzatore predefinito del browser per i pdf. Il floatingPane permette di essere spostabile, ridimensionabile e di poter andare a tutto schermo.

Da notare che sono persistite le preferenze dell'utente di posizionamento e di sizing del floatingPane, permettendo quindi di poter facilmente aprire insieme ed affiancare più report pdf.

Le report .xlsx vengono scaricate

Le report .docx vengono scaricate

openGwExportableReport(params)

  • codReport String, required codice univoco della report
  • format String, required, allowed values: ['XLSX', 'PDF', 'DOCX'] Non necessario solo quando askForModelAndFormat true
  • codModel String, optional. If omitted the default is used
  • askForModelAndFormat boolean, default false quando è a true format non serve
  • hasParametersToPrompt boolean, optional, default false. Se provvisto si evita di recuperare l'informazione (usato internamente)
  • nameReport String, optional (verrà usato esclusivamente come titolo per il floatingPane del pdf)
  • gwClassName String, optional (used with queryParameter)
  • queryParameter Object, optional (used with gwClassName)

Esempio apertura report dato il codice, in formato xlsx ed usando il modello di default:

var params = {
	codReport: codReport,
	format: 'xlsx'
};
openGwExportableReport(params);

Esempio apertura report dato il codice, con richiesta di formato di esportazione e modello all'utente:

var params = {
	codReport: codReport,
	askForModelAndFormat: true
};
openGwExportableReport(params);

Esempio apertura report dato il codice, applicando alla report dei filtri di lista/dettaglio

var params = {
	codReport: codReport,
	gwClassName: gwClassName,
	queryParameter: queryParameter
};
openGwExportableReport(params);

UI basata sulla classe gwr_report. La gestione è resa fruibile al solo Solution Manager.

Le report possono essere di due tipologie:

  • di prodotto. Sono le Report standard di base che sono predefinite a livello di prodotto.
  • custom Sono le Report creabili e configurabili in autonomia dal Solution Manager (imprescindibile lo sviluppo di un file .jasper che presuppone competenze negli ambiti SQL + JasperReport + convenzioni Geoweb).

Le report di prodotto, a differenza di quelle custom non possono essere mai modificate/eliminate, ma al massimo disabilitate globalmente dal Solution Manager. Sono inoltre possibili modifiche ai modelli Report associati. Le Report custom possono essere create e modificate liberamente in tutti gli aspetti. Il completo controllo delle modalità di erogazione delle Report è sempre in capo al Solution Manager.

Caratteristiche comuni:

  • formati di esportazione configurabili (e fruibili su richiesta da parte dell'utente finale)
  • disabilitabili globalmente
  • rese fruibili selettivamente alle varie Funzioni di destinazione
  • disposte in una Categoria Report (dipendente dalla Funzione)

Dati

Per le report di prodotto (non custom), il dettaglio di classe presenta un limitato set di proprietà configurabili.

Le Report custom/nuove sono più configurabili:

Le risorse Report sono volutamente non required per permetterne un caricamento successivo. In caso di assenza ne viene comunque data comunicazione a runtime al momento di lanciare la report.

Nota l'adozione per l'abilita del nuovo switchWidget introdotto con la issue #1322

Modelli associati

Il SM può esplicitare quali Modelli Report, definiti in un'anagrafica a parte, sono applicabili alla Report corrente. Di questi modelli, uno è obbligatoriamente eletto a default.

Da notare che il flag di default non si configura dal dettaglio del Modello Report, ma direttamente dalla lista di associazione (LinkListNam). Questo in quanto un Modello può essere il default di una Report e non di un'altra.

La scelta del modello di default è possibile grazie all'uso combinato del check in edit nella lista di associazione (sviluppo collegato isEditableInRelatedGwClassList issue #1190) e il trigger groovy di classe, che assicura l'unicità del Modello di default per la Report.

Parametri disponibili

Ogni Report permette di definire un elenco esclusivo di parametri, che sono resi disponibili ed utilizzabili nel file .jrxml (dalla cui operazione di build viene generato il file .jasper).

Funzioni di destinazione

In questo tab il SM decide per quali Funzioni questa Report è resa fruibile. Affinchè la Report compaia effettivamente all'utente finale, essa deve essere anche posizionata (tramite drag and drop) nella Categoria di pertinenza nella scheda dedicata riservata al Solution Manager.

Categorie Report

Questo elenco è di sola consultazione. Il posizionamento di una Report nella Categoria di pertinenza può essere configurato solo dal Solution Manager nella apposita scheda dedicata, dove viene configurato il layout delle Report per una determinata Funzione.

Filtri

Scegliere se questa Report può essere esportata anche dalle liste e dai dettagli delle anagrafiche selezionate.

I dati delle Report vengono parzializzati in base a filtri determinati dal contesto: vale a dire i record visibili in lista ed il singolo record di dettaglio.

Il flag 'Esportabile da lista' abilita la possibilità di esportare la Report nelle anagrafiche selezionate, usando i filtri sui dati correnti. In aggiunta il flag 'Esportabile da dettaglio' abilita l'esportazione anche a livello del singolo dettaglio.

Si può opzionalmente configurare che la Report Esportabile sia lanciabile, al posto che dai (button 'more options') della toolbar/riga lista, da un button dedicato nella toolbar (scelta disponibile sia per la lista che per il dettaglio)

Le anagrafiche interessate vanno esplicitate, assicurandosi preventivamente della compatibilità delle stesse con la Report corrente.

UI basata sulla classe gwr_model. La gestione è resa fruibile al solo Solution Manager.

Un Modello Report è un set di stili formato da un Header e da un Footer. Questi vengono applicati al template della Report al momento della sua generazione. Header e Footer possono essere di varie tipologie:

  • IMMAGINE
  • TESTO
  • HTML

I tipi di Header e Footer possono essere differenti e sono correttamente gestiti.

Ogni Report ha un modello di default, esplicitabile nella scheda di gestione della Report stessa.

L'interfaccia cambia dinamicamente in base agli eventi attributi.

L'allineamento è passato a runtime alla Report con appositi parametri che vengono valutati dal template scaricabile.

IMMAGINE

Sono supportate immagini con estensione: .svg, .png, .jpg, .jpeg. L'altezza dell'immagine sarà adattata per ricoprire tutto lo spazio disponibile in verticale. Il fattore di forma dell'immagine sarà sempre preservato

TESTO

Viene supportato un markup HTML basilare (come colore e dimensione del testo, elenchi, font e link) generabile con l'editor dedicato.

HTML

Nota: feature sperimentale HTML rispetto a TESTO, permette di scrivere direttamente codice HTML. Sono supportate più proprietà (padding, margin, background-color, etc..) Da notare che l'HTML verrà convertito in un'immagine quando verrà applicato alla report. Quindi elementi come i link non funzioneranno nella report.

UI basata sulla classe gwr_param. La gestione è resa fruibile al solo Solution Manager.

Un Parametro Report è una informazione predefinita e statica che può essere di tipo TESTO od IMMAGINE, identificata in maniera univoca, che può venire passata al momento di generare la Report. Il fine è quello di inserire nelle Report testo od immagini (spesso in più punti della stessa) definiti preventivamente ed un sola volta. Un Parametro deve essere esplicitamente associato alla Report al fine di poter essere richiamato nel file delle risorse della Report.

UI basata sulla classe gwr_report_category. La gestione è resa fruibile al solo Solution Manager.

Una Categoria Report è un etichetta di raggruppamento.

L'associazione delle Report alle Categorie Report può essere configurata solo dal Solution Manager nella scheda dedicata.

Da notare che il modello dati permette al SM di rendere visibile una Report in una certa Categoria, che può essere differente Funzione per Funzione.

Scheda di gestione layout dedicata al Solution Manager

In questa scheda dedicata al Solution Manager (che quindi dovrebbe essere raggiungibile solo da una Funzione specifica riservata al SM) esso determina il layout di presentazione delle Report per la Funzione selezionata.

Legenda comandi

  1. toolbar della gwExportableReportSMTab
  2. button 'Refresh'
  3. button 'more options', con azione 'Copia layout da altra Funzione'
  4. button 'Nuova Categoria Report'
  5. area istruzioni
  6. selettore Funzione
  7. switch Anteprima
  8. nome Categoria Report
  9. button 'Edita Categoria Report': apre il dettaglio della Categoria Report
  10. button 'Rimuovi tutte le Report dalla Categoria'
  11. grip per drag&drop Categoria: il drop avviene portandola oltre la metà della precedente/successiva
  12. nome Report Esportabile
  13. switch attiva/off Report la report pur rimanendo associata alla categoria, non è più visibile a tutte le Funzioni
  14. abilita formato xlsx
  15. abilita formato pdf
  16. abilita formato docx
  17. button 'Edita Report': apre il dettaglio della Report
  18. button 'Rimuovi Report dalla Categoria'
  19. grip per drag&drop Report: il drop avviene portandola oltre la metà della precedente/successiva

La prima operazione da fare è agire sul selettore di Funzione in alto a sinistra.

Ognuna delle Report associate alla Funzione (area a destra), può essere inserita in una sola Categoria tramite drag&drop.

Una volta dentro una Categoria, ogni report può essere spostata ed riordinata tramite drag&drop (anche verso le altre Categorie). Il drop avviene portandola oltre la metà della precedente/successiva. E' possibile editare la Report tramite dettaglio di classe. E' possibile rimuovere la singola Report da una categoria.

Anche le Categorie possono essere riordinate tramite drag&drop. Il drop avviene portandola oltre la metà della precedente/successiva. E' possibile editare la categoria tramite dettaglio di classe. E' possibile rimuovere tutte le Report della specifica categoria.

Tutti i cambiamenti effettuati vengono subito persistiti.

leafItem XML

La scheda è integrabile nel layout del gwProject come 3rd level menu, usando questo leafItem senza parametri:

<leafItem name="gwExportableReportSM" label="Scheda gestione layout Exportable Report (SM)" image="eyJjc3NDbGFzcyI6ImZhLXNvbGlkIGZhLWZpbGUtZXhwb3J0Iiwid2lkdGgiOiIzMnB4IiwiaGVpZ2h0IjoiMzJweCIsImNvbG9yIjoiIzAwN0FDMiJ9" type="gwExportableReportSM" escapeLabel="true" disabled="false" hidden="false">
</leafItem>

API javascript

Codice equivalente per aprire questa scheda.

var title = '';
var params = {};
var tab = openGwExportableReportSMTab(params, title);

Per le liste (gwClassList, linkList, liste workflow tutte) delle classi che sono state configurate come filtrabili dal SM (nell'apposita sezione del dettaglio della Report), compare contestualmente a seconda della configurazione:

  • un'azione in toolbar
  • un menuItem in button '…' (more actions)

In entrambi i casi, al click si apre sempre un dialog del tutto simile a quello del cruscotto per l'utente finale.

Per le liste i dati presenti nella report saranno esattamente quelli risultanti dai filtri impostati correntemente per la lista (NON SEMPLICEMENTE I SELEZIONATI).

Analoghi comportamenti sono disponibili nei dettagli delle classi configurate.

  • gwusermanual/interface/dashboard_set_configurabili.1733739507.txt.gz
  • Ultima modifica: 2024/12/09 11:18
  • da giorgio.scali