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.
In its initial state, the __User class has the attributes shown in the figure.
profile identifies its profile, which can only have the available Profile-schemas as value (see Create a default attribute).
Anything modeled on the __User class in addition to the
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.
timezone, etc.) and pertain to authentication or display configuration information.
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 (
- impose restrictions on domain.
Some default attributes (such as
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 :
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.