Modella viste applicative e profili utente

Nella lezione precedente #

Con le ultime modifiche apportate, abbiamo rappresentato nel modello tutte le informazioni elencate nella roadmap dello Scenario di esempio.

Al momento, nel modello è presente una sola vista applicativa Application. Chiunque accede a essa può quindi vedere le liste complete di: impiegati (compresi i loro incarichi), progetti, fatture e pagamenti; può inoltre modificare questi dati senza alcuna restrizione.

Partiziona l’accesso ai dati #

La gestione completa del database è un diritto che vorremmo assegnare solamente agli amministratori del sistema, mentre vorremmo che tutti gli altri utenti avessero accesso solo alla porzione di database di loro competenza. Dai profili utente descritti nello Scenario, sappiamo che il reparto contabilità è interessato alle classi presenti nel diagramma parziale Accounting, mentre il reparto risorse umane è interessato a quelle del diagramma Staff.

Il nostro obiettivo è ora partizionare i dati del sistema definendo più applicazioni, garantendo l’accesso a tali applicazioni a specifici gruppi di membri; realizziamo questa separazione combinando tre diverse tecniche di partizionamento: verticale, orizzontale e per profilo utente.

Come al solito, prima di procedere ti consigliamo di archiviare la versione corrente del modello. Dopodiché, arresta la Cloudlet Workforce, apri TutorialEngine nel Designer e spostati sull’Application Schema .

1. Partizionamento verticale mediante viste applicative multiple #

Abbiamo già introdotto il concetto di partizionamento: l’abilitazione o disabilitazione di elementi del database in una vista applicativa rappresenta un partizionamento verticale. Questa operazione è utile perché ci consente di definire più applicazioni, ciascuna delle quali consente di accedere a una porzione specifica del database.

Come sappiamo, possiamo disabilitare un elemento cliccandoci sopra quando nella Palette è selezionata l’icona Toggle management policy. In base alla struttura del modello, la disabilitazione di un elemento coinvolge tutti gli elementi che dipendo da esso; ad esempio, quando disabilitiamo una classe (ovvero il suo default class role), assieme a essa vengono disabilitati tutti i suoi attributi e i ruoli per cui è parent, insieme alle eventuali classi part, a meno che queste ultime non partecipino in altre relazioni.

Aggiungi nuove viste applicative #

Nella lezione precedente abbiamo creato i due diagrammi Accounting e Staff per avere una visione compatta di due aree distinte del modello; possiamo sfruttare questa idea per individuare due nuove viste applicative.

Per prima cosa, rinomina Application in Administration facendo doppio click su di essa dal tab Schemas. Dato che ha tutte le classi abilitate, possiamo considerarla come la vista che verrà usata dagli amministratori di sistema.

È possibile aggiungere una nuova vista applicativa cliccando sull’icona New application; tuttavia così facendo creeremmo una vista da zero, perdendo i class warning e i filtri sui ruoli definiti su Administration. Vogliamo invece conservare queste personalizzazioni anche nelle nuove viste; procediamo pertanto in un altro modo:

• Fai click destro su Administration per aprire il suo Application menu; da qui seleziona Clone: viene creata una copia esatta della vista, che ne conserva tutte le personalizzazioni. Rinomina quest’ultima in Accounting;
• Vogliamo che da questa vista applicativa si possano gestire le associazioni in entrata verso i progetti, senza che questi possano essere creati, modificati o eliminati; seleziona Accounting, spostati sul diagramma Staff e disabilita tutti i class role presenti: Employee, Qualification, Team, Activity e Project. Nota come Address e Project non siano diventate grigie: la prima infatti partecipa come target in altre associazioni, mentre la seconda è part per Customer. Noterai anche che Activity_type non possiede un class role perché le classi di tipo Enum non sono indipendenti.
• Clona di nuovo Administration e rinomina la copia in Staff_management; selezionala, spostati sul diagramma Accounting e disabilita tutti i class role eccetto Project (Incoming_Invoice, Outgoing_Invoice, Payment, Supplier e Customer); per Project, disabilita tutti gli attributi query sul calcolo del bilancio e i ruoli Project.customer e Project.supplier. Infine, spostati sul diagramma Staff e disabilita il class role di Activity.

Qui sotto mostriamo le modifiche ai tre diagrammi del modello dati nelle due viste appena definite:

Accounting #

Staff #

Administration #

Gli elementi disabilitati in una vista applicativa sono disabilitati in tutti i diagrammi. Puoi verificare questa affermazione osservando come cambia il diagramma Administration scorrendo le tre viste (Administration, Accounting e Staff_management).

Definisci permessi per profilo utente #

Ora che abbiamo suddiviso il database in più “spicchi”, dobbiamo stabilire chi potrà accedere a ciascuna vista applicativa; al momento, infatti, ogni membro della Cloudlet ha accesso a tutti gli Application Schema che abbiamo definito. Dobbiamo quindi partizionare ulteriormente l’accesso, e per farlo introduciamo i Profile Schema . Citando la panoramica di Livebase:

I Profile Schema descrivono i grant (diritti) che gli utenti con quel profilo hanno nel sistema. Un profilo può essere abilitato o meno ad accedere a un insieme di viste applicative, e per ciascuna vista/Application schema è possibile specificare i diritti di lettura e modifica sugli oggetti resi accessibili dalla vista.

Al momento nella tab Schemas è presente il solo Profile Schema di default Member (oltre al profilo Guest, che non trattiamo qui). Clicca su Member per aprire la scheda Settings. Da questo pannello possiamo configurare i seguenti aspetti:

• Access to applications: è presente una checkbox per ogni vista applicativa nel modello. Quando una vista applicativa è spuntata, è possibile scegliere il tipo di accesso tra completo (Full write), sola lettura (Read only) oppure personalizzato (Custom);
• Editing of cloudlet settings: consente di assegnare al profilo il diritto di modifica delle impostazioni della Cloudlet;
• Management of cloudlet members: consente di assegnare al profilo il diritto di creare, modificare o eliminare membri della Cloudlet.

Quando aggiungiamo una nuova vista applicativa, tutti i profili esistenti vi ottengono accesso. Questo accade perché ogni vista applicativa deve avere almeno un profilo che può accedervi; pertanto il profilo Member al momento può utilizzare tutte le nostre applicazioni.

Creiamo due nuovi profili: clicca in alto sull’icona New profile e rinominalo in Accountant; apri la sua scheda Settings e spunta la voce Use application Accounting. Ripeti il procedimento creando un profilo Staff_manager che ha accesso alla vista Staff_management . Per entrambi i profili, per ora, lascia il tipo di accesso Full write.

Osserva la vista applicativa Staff_management: su di essa abbiamo mantenuto abilitata la classe Project, mentre abbiamo disabilitato Activity; questo perché ci aspettiamo che un responsabile possa gestire almeno ciò che in un progetto è relativo allo staff – cioè l’assegnazione del responsabile tecnico – mentre invece non ci aspettiamo che sia lui a registrare le attività degli impiegati, ma che siano loro stessi a farlo da un’area personale.

Il Permission Schema #

Ragioniamo sul primo problema: vogliamo garantire un accesso parziale alla classe Project per questo profilo, e impedire ai responsabili delle risorse umane di creare, eliminare o modificare altri attributi dei progetti oltre al ruolo Project.director. Per fare questo, dobbiamo personalizzare il diritto di accesso: apri la scheda Settings di Staff_manager e clicca sull’icona a fianco della spunta Use application Staff_management per aprire una nuova vista sul nostro modello.

Questa prende il nome di Permission Schema , e mostra i permessi che un profilo ha relativamente a una vista applicativa per la quale ha diritto di accesso. In questo contesto il diagramma cambia aspetto e permette di visualizzare e modificare puntualmente il tipo di accesso per ciascuna classe, attributo o relazione del modello per il Profile Schema selezionato.

Osserva il diagramma: così come un Application Schema dipende dal Database Schema su cui è definito, un Permission Schema dipende dall’Application Schema per il quale esso specifica i permessi (grants) di quel Profile Schema . Pertanto, gli elementi disabilitati nella vista applicativa corrispondente sono disabilitati anche nel Permission Schema; in particolare, per le classi e i ruoli disabilitati viene mostrato solamente il contorno in grigio, mentre gli attributi disabilitati non compaiono affatto e lasciano degli spazi vuoti nelle classi.

Ciascun elemento abilitato ha qui tre possibili stati:

• Editabile: il profilo ha accesso completo a quell’elemento; può compilarlo se è un attributo e associare oggetti se è un ruolo;
• Sola lettura: il profilo può vedere quell’elemento, ma non può modificarlo;
• Disabilitato: da non confondere con gli elementi disabilitati ereditati dall’application schema; anche a questo livello possiamo disabilitare elementi del diagramma, ma sempre nell’ambito di un solo Profile Schema.

Cliccando su un elemento del diagramma possiamo invece scegliere il suo stato tra le tre configurazioni elencate sopra. Come avrai notato, attributi derivati, di piattaforma e di tipo serial costituiscono un’eccezione: poiché non è possibile alterarne direttamente il valore, possiamo consentirne la lettura ma non la scrittura.

Classi e composizioni hanno un livello di dettaglio ancora più fine, rappresentato da tre icone nel footer o sul ruolo part:

• rappresenta il diritto di creazione di nuovi oggetti;
• rappresenta il diritto di modifica di oggetti;
• rappresenta il diritto di eliminazione di oggetti.

Cliccando su un’icona possiamo disabilitare o abilitare il diritto corrispondente; quando tutti e tre sono disabilitati, la classe e tutti i suoi attributi passano automaticamente in sola lettura.

Modifichiamo i permessi per la classe Project:

2. Partizionamento orizzontale mediante class filters e user properties #

La vista Staff_management non è pensata per consentire l’accesso ai singoli impiegati oppure ai team manager; dobbiamo creare altre due viste, più ristrette, che mostrino solo i dati di interesse per la tipologia di utente: gli impiegati devono avere accesso al proprio oggetto employee, corredato di incarichi e attività; i team manager devono avere accesso al team e ai suoi membri.

Dobbiamo quindi realizzare un ulteriore partizionamento orizzontale dei record ma in base a una qualche corrispondenza con le informazioni associate ai membri della Cloudlet. Vediamo come fare:

Aggiungi la vista User_area #

Per prima cosa creiamo una nuova vista applicativa, stavolta clonando Staff_management: rinomina la copia in User_area , abilita il class role di Activity e disattiva quelli di Qualification, Team e Project. Inoltre, abbi cura di rimuovere la voce di menu Manage Objects Project_assignment, che in questo contesto non è rilevante. Rimangono quindi solamente le voci di menu relative a Employee e Activity.

Crea un nuovo profilo User, apri le sue Permissions e spunta Use application User_area; dopodiché, apri il corrispondente Permission Schema e togli i diritti di creazione ed eliminazione per le classi Employee e Project_assignment. Imposta i ruoli Employee.team e Project_assignment.project in sola lettura: non vogliamo infatti che gli utenti possano creare o eliminare altri impiegati o incarichi, né che possano riassegnarsi a un altro team o spostare i loro incarichi su altri progetti. Infine imposta gli attributi date_joined e hourly_cost in sola lettura, così da impedire agli utenti di aumentare il proprio costo orario.

La vista applicativa e il profilo appena definiti ora appaiono come in figura (per comodità, mostriamo solo il diagramma Staff):

User_area:

Permessi di User in User_area:

A questo punto dobbiamo trovare un modo per mostrare, a ciascun utente/impiegato con profilo user, solamente l’oggetto employee che lo rappresenta nel sistema. Introduciamo quindi i Class Filter, ovvero filtri a livello applicativo sulle classi. In modo analogo a un Selection filter, un Class filter è una condizione booleana che viene valutata su tutti gli oggetti della classe, e serve a filtrare dalla lista della classe i record che non soddisfano la condizione.

Per definire la condizione dobbiamo far uso delle User properties, ovvero gli attributi relativi all’utente corrente della Cloudlet, che ha una sessione aperta e sta lavorando sui dati (__CurrentUser); in particolare sfruttiamo l’attributo __CurrentUser.username per realizzare una corrispondenza tra il membro della Cloudlet e l’employee del modello.

Nel caso in cui voglia disabilitare la propagazione di un Class filter su un ruolo, ti basta aprire il suo Role menu e togliere la spunta alla voce Apply class filters. Ad esempio, nel nostro caso è corretto non applicare il filtro di classe per il ruolo riflessivo Employee.supervisor, dato che in questo ambito abbiamo già definito un filtro sul ruolo che esclude sé stessi dalla lista degli associabili e ci interessa invece mostrare il resto degli impiegati.

Aggiungi la vista Team_management #

La vista User_area è completa. Occupiamoci ora della gestione dei team:

• Dobbiamo creare una vista identica a User_area, che differisce esclusivamente per il Class filter che applichiamo a Employee; pertanto, clona a partire da User_area e rinomina la copia in Team_management.
• Crea un nuovo profilo Team_manager e assegnagli l’accesso a Team_management. Dopodiché, modifica il corrispondente Permission Schema come sopra per i permessi di User in User_area.
• Spostati sulla vista Team_management , riapri il Class filters manager di Employee, rimuovi il filtro userProfileOnly (che è stato copiato qui, avendo clonato a partire da User_area) selezionandolo e cliccando su Delete, e aggiungi un altro filtro chiamato sameTeamOnly, con l’espressione Employee.team_name = __CurrentUser.team. Anche qui, ricordati di disabilitare il filtro di classe per il ruolo Employee.supervisor.
• Sfruttando l’esistenza del concetto di Team nel modello, possiamo infatti suddividere i membri della Cloudlet negli stessi team a cui appartengono nella realtà. In questo modo, il team manager potrà gestire non solo la sua area personale, ma anche quelle degli impiegati che fanno parte del suo team.
• Anche qui dobbiamo filtrare le activities mostrando solo quelle dei membri del team. Dobbiamo mostrare su Activity il nome del team per poterlo usare nel filtro, perciò aggiungi una query a Employee.team_name chiamata /employee_team così come abbiamo fatto per /employee_username. Dopodiché, rimuovi il filtro userProfileOnly definito su Activity e aggiungi un filtro chiamato di nuovo sameTeamOnly, con l’espressione Activity.employee_team = __CurrentUser.team.

3. Abilita la gestione degli utenti #

In Crea la tua prima applicazione, avevamo detto di ignorare la presenza del warning che esortava a includere nel modello la classe di piattaforma __User. Tuttavia, se non includiamo questa classe, non possiamo gestire gli utenti della Cloudlet e questo rende inutile il partizionamento orizzontale che abbiamo modellato finora.

Spostati sul diagramma Administration, clicca col tasto destro in un punto libero della Canvas e passa il mouse sull’opzione New platform class. Dal menu che comparirà seleziona quindi User per far apparire la classe __User nel diagramma attualmente visualizzato:

Non occorre che la classe sia collegata alle altre: è sufficiente la sua presenza per abilitare la gestione delle utenze.

Se adesso verifichi nuovamente i warning sollevati sul modello, facendo clic sul pulsante Check in basso a destra, ne noterai uno nuovo:

Abbiamo incluso la classe __User nel nostro modello, e come puoi verificare è abilitata di default in tutte le viste applicative, ma nessuno dei profili che abbiamo definito ha i permessi di scrittura sulla classe.

Seleziona un profilo dalla scheda Schemas per aprirne i Settings, quindi osserva la sezione Management of cloudlet members:

Sono presenti tre checkbox: Create cloudlet members, Edit cloudlet members e Delete cloudlet members, che abilitano rispettivamente la creazione, la modifica e l’eliminazione degli utenti i cui profili sono elencati nelle relative tabelle. Per concedere un particolare permesso, spunta una delle checkbox e aggiungi i profili per cui quel permesso è valido facendo clic sul pulsante Add. Per revocare i permessi su un profilo aggiunto precedentemente, selezionalo e fai clic sul pulsante Remove. Nota che la tabella di Edit cloudlet members ha due colonne: Original profile e New profile, e i suoi record rappresentano transizioni fra profili; è possibile modificare gli attributi di qualsiasi utente il cui profilo compaia nella colonna Original profile, ma quest’ultimo è modificabile solo se è presente la relativa transizione.

Nel nostro caso, vogliamo concedere i permessi sugli utenti ai profili Administrator e Staff_manager: Administrator avrà pieni diritti di creazione, modifica ed eliminazione, mentre Staff_manager potrà gestire liberamente tutti gli utenti che non siano amministratori.

Queste le tabelle Create cloudlet members, Edit cloudlet members e Delete cloudlet members per entrambi i profili:

Administrator #

Staff_manager #

Siccome solo Administrator e Staff_manager potranno gestire gli utenti, non ha senso lasciare abilitata la classe per tutte le applicazioni, quindi disabilitala nelle viste Accounting, Team_management e User_area.

Ora il nostro modello è davvero completo. Puoi salvarlo e chiudere il Designer.

Aggiorna e controlla l’applicazione #

Tornato alla Dashboard, avvia come al solito la Cloudlet Workforce risolvendo tutte le issues di allineamento. Come puoi notare dal warning mostrato, le modifiche che abbiamo apportato ai profili hanno prodotto la conseguenza che nessun membro della Cloudlet ha un profilo che gli consente di accedere alle applicazioni. Infatti, inizialmente avevamo il solo profilo Member, che è stato sostituito da Administrator, Accountant, Staff_manager, Team_manager e User. Possiamo risolvere il problema accedendo alla Cloudlet con le credenziali del default member e facendo clic sull’icona della matita accanto al suo nome, nell’area Members della home page: seleziona un profilo a piacere tra quelli disponibili nel dropdown Profile, fai clic su Save, quindi ripeti il login; dovresti ora vedere almeno un’applicazione nell’area Applications.

Prenditi il tempo che vuoi per controllare che ogni vista applicativa funzioni correttamente, cambiando di volta in volta il profilo ripetendo i passaggi sopra.

In alternativa, puoi verificare il funzionamento del partizionamento orizzontale in questo modo: accedi con il default member e assicurati che il suo profilo sia Administrator o Staff_manager. Entra nell’applicazione Administration o Staff management e crea un nuovo utente con il servizio _User___create assegnandogli uno username, un profilo a scelta e un indirizzo email. Presso tale indirizzo ti sarà inviato un link da utilizzare per definire la password necessaria ad accedere con l’utente appena creato: se il partizionamento orizzontale è stato modellato correttamente, dovresti vedere le applicazioni per cui il relativo profilo è stato abilitato.

Conclusioni #

Con questa lezione abbiamo implementato tutti i requisiti che avevamo elencato nella roadmap mostrata all’inizio del corso e siamo pronti per mettere l’applicazione in esercizio.

Clicca sul bottone per scaricare il modello che abbiamo realizzato in questa lezione:

TutorialEngine_finale.xml

Nella prossima lezione… #

Esamineremo alcune tecniche di manutenzione avanzata, utili nel caso in cui fosse necessario apportare modifiche durante l’esercizio dell’applicazione: Riallinea manualmente il database via SQL.