In management systems, scenarios in which the data model is partially or entirely dependent on individual users of the system are quite common; for example, in e-commerce, concepts such as orders and shopping carts are strictly tied to the end-user account, which can only view and manage data that belongs to it.
The purpose of the __User class is therefore to provide the modeler with a representation of the users of the generated application and Cloudlet at the data domain level. Conceptually, in Livebase a user is both a platform object (involved in the Cloudlet authentication process) and a domain object, hence modelable. In fact, the modeler can extend the default information of the __User class by adding attributes and relationships with other modeled classes, so as to bind entire parts of the engine to the Cloudlet user profile.
In exchange for this flexibility, modelers are responsible for enabling the __User class in at least one application view of the engine. User creation is initially delegated to the administrator user, the only user that can be generated via the Dashboard. More information is available in the release notes.
La classe __User
In its initial state, the __User class has the attributes shown in the figure. username and email identify the user, while profile identifies its profile, which can only have the available Profile-schemas as value (see Create a default attribute).
These default attributes are created by default. Unlike the other default attributes, you cannot remove them from the class and they are always required.
Anything modeled on the __User class in addition to the username, profile, and email attributes can only be optional; in fact, to support scenarios in which Livebase must automatically generate a user, it is necessary to guarantee the absence of constraints towards the modeled parts, which the system is unable to automatically value unlike the default attributes. Therefore, it is not possible to declare unique constraints or indices on any other attribute of the __User class, nor set it as required.
Create the __User class #
Right-click on a free spot in the workspace (Canvas) to open the Database menu; from the drop-down menu choose New platform class > User. Alternatively, click on the palette button(Create platform class User).
Predefined attributes #
The User properties are modelable and correspond to the Predefined attributes within the __User class. Predefined attributes are native pre-modeled attributes over which the modeler has only partial control, as they refer to the Cloudlet user’s intrinsic properties (e.g. username, timezone, etc.) and pertain to authentication or display configuration information.
The __User class, on which all available default attributes have been enabled
Enable a predefined attribute #
Right-click on the __User class to open its Class menu and select New predefined attribute; choose the default attribute from the list.
The default attributes depend on the user’s properties. For this reason, the following operations normally available for native attributes are not supported:
- modify the data type;
- impose integrity constraints (make the attribute required);
- impose a unique constraint (
Make Unique). - impose restrictions on domain.
Some default attributes (such as profile, language, dateFormat, etc…) have domains that cannot be changed in the engine model and can only take on the values currently supported by Livebase. Instead, the value of the profile attribute depends on the name of one of the Profile Schemas present in the engine model. Platform attributes and derived attributes are supported, both query and math.
Referencing the __User class #
It’s possibile to express relationships of any kind from the __User class and other classes to it, but the outgoing relationships must have the minimum cardinality of the target role equal to zero: as we have seen, every element modeled on __User (except for the default attributes present by default) must be optional. For this reason, the Exactly one (1) and One or more (1N) options are disabled in the Role menus of the outgoing relations’ targets. Both associations and compositions are allowed.
Referencing default attributes of current user #
It is always possible to reference the predefined attributes of the current user in expressions using the __CurrentUser syntax. The of the Expression editor opens the list of User properties, i.e. information about the current user of Cloudlet at the time the expression is evaluated.
For example, you can define in any class a math attribute that returns as value the full name of the user (the first name followed by the last name) by entering the following expression in the editor : concat(__CurrentUser.firstName,__CurrentUser.lastName).
User Management in the generated application #
User management is supported throughout the generated application:
- In the Plugin environment, the generated SPI includes the
Entityinterfaces for managing the _User class as a normal engine model class; - in GraphQL, all the basic read and write services for the __User class are generated, with the difference in the name of the type: _User instead of __User, since the use of the double underscore in GraphQL is reserved for schema metadata.
Also in GraphQL and from Plugin, deleting a __User causes the deleted=true flag to be set.