Nei sistemi gestionali, sono abbastanza frequenti scenari in cui il modello dati dipende parzialmente o interamente dai singoli utenti del sistema; ad esempio, nell’e-commerce, concetti come gli ordini e il carrello sono strettamente legati all’account dell’utente finale, che può visualizzare e gestire esclusivamente i dati che gli appartengono.
Lo scopo della classe __User è dunque quello di fornire al modellatore una rappresentazione degli utenti dell’applicazione generata e della Cloudlet a livello di dominio dati. Concettualmente, in Livebase un utente è sia un oggetto di piattaforma (coinvolto nel processo di autenticazione delle Cloudlet) sia un oggetto di dominio, quindi modellabile. Il modellatore può infatti estendere le informazioni di default della classe __User aggiungendo attributi e relazioni con altre classi modellate, così da vincolare intere parti del modello al profilo dell’utente della Cloudlet.
In cambio di questa flessibilità, i modellatori hanno la responsabilità di abilitare la classe __User in almeno una vista applicativa del modello per abilitare la gestione degli utenti nell’applicazione generata. La creazione degli utenti è inizialmente delegata all’utente amministratore, l’unico a poter essere generato tramite la Dashboard. Maggiori informazioni sono disponibili nelle note di rilascio.
Nello stato iniziale, la classe __User possiede gli attributi riportati in figura. username
e email
identificano l’utente, mentre profile
identifica il suo profilo, che può assumere un valore ristretto ai Profile schema disponibili nel modello (vedi Creare un attributo predefinito).
Questi attributi predefiniti sono creati di default. A differenza degli altri attributi predefiniti, non è possibile rimuoverli dalla classe e sono sempre required.
Tutto ciò che viene modellato sulla classe __User in aggiunta agli attributi username
, profile
e email
non può che essere opzionale; per supportare gli scenari in cui Livebase deve generare automaticamente un utente, è infatti necessario garantire l’assenza di vincoli verso le parti modellate, che il sistema non è in grado di valorizzare automaticamente a differenza degli attributi predefiniti. Non è dunque possibile dichiarare vincoli di unicità o indici su qualunque altro attributo della classe __User, né impostarlo come required.
Creare la classe __User #
Fai click destro su un punto libero nell’area di lavoro (Canvas) per aprire il Database menu
; dal menu a tendina scegli New platform class > User
. In alternativa, clicca sul pulsante della palette(Create platform class User
).
Attributi predefiniti #
Le User properties sono modellabili e corrispondono ai Predefined attributes all’interno della classe __User. Gli attributi predefiniti sono attributi nativi pre-modellati sui quali il modellatore ha un controllo solo parziale, in quanto fanno riferimento alle proprietà intrinseche dell’utente della Cloudlet (ad es. username
, timezone
, etc.) e riguardano informazioni relative all’autenticazione o alla configurazione di visualizzazione.
Abilitare un attributo predefinito #
Fai click destro sulla classe __User per aprire il suo Class menu
e seleziona New predefined attribute
; scegli l’attributo predefinito dalla lista.
Gli attributi predefiniti dipendono dalle proprietà dell’utente. Per questo motivo, non sono supportate le seguenti operazioni normalmente disponibili per attributi nativi::
- modificare il tipo di dato;
- imporre vincoli di integrità (rendere l’attributo required);
- imporre un vincolo di unicità (
Make Unique
). - imporre restrizioni sul dominio.
Alcuni attributi predefiniti (come profile
, language
, dateFormat
, etc…) hanno domini non modificabili nel modello e possono assumere solo i valori attualmente supportati da Livebase. Il valore dell’attributo profile
dipende invece dal nome di uno dei Profile Schema presenti nel modello. Sono supportati attributi di piattaforma e derivati sia di tipo query che math.
Referenziare la classe __User #
È consentito esprimere relazioni di qualunque tipo a partire dalla classe __User e da altre classi verso di essa, ma le relazioni uscenti devono avere la cardinalità minima del ruolo target pari a zero: come abbiamo visto, ogni elemento modellato su __User (ad eccezione degli attributi predefiniti presenti di default) deve essere opzionale. Per questo motivo, nei Role menu
dei target delle relazioni uscenti sono disabilitate le opzioni Exactly one (1
) e One or more (1N
). Sono consentite sia associazioni sia composizioni.
Referenziare gli attributi predefiniti dell’utente corrente #
È sempre possibile referenziare nelle espressioni i predefined attributes dell’utente corrente attraverso la sintassi __CurrentUser
. L’icona dell’Expression editor apre la lista delle User properties, ovvero informazioni relative all’utente corrente della Cloudlet al momento in cui l’espressione è valutata.
Ad esempio, è possibile definire in una classe qualsiasi un attributo math che restituisca come valore il nome completo dell’utente (il nome seguito dal cognome) inserendo nell’editor la seguente espressione: concat(__CurrentUser.firstName,__CurrentUser.lastName)
.
Gestione degli utenti nell’applicazione generata #
La gestione degli utenti è supportata in tutta l’applicazione generata:
- in ambito Plugin, lo SPI generato include le interfacce
Entity
per la gestione della classe __User come una normale classe del modello; - in GraphQL, vengono generati tutti i servizi base di lettura e scrittura per la classe __User, con la differenza nel nome del type: _User invece di __User, dato che l’utilizzo del doppio underscore in GraphQL è riservato ai metadati dello schema.
Anche in GraphQL e da Plugin, l’eliminazione di uno __User comporta l’impostazione del flag deleted=true
.