skip to main content

__User class

The __User class is a platform class whose instances correspond to Cloudlet users.

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 model 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 model to enable user management in the generated application. 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.

 The __User class

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).

Create __User class

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.

Default attributes

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.

Enable a predefined attribute

The default attributes depend on the user’s properties. For this reason, the following operations normally available for native attributes are not supported::

Some default attributes (such as profile, language, dateFormat, etc…) have domains that cannot be changed in the 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 model. Platform attributes and derived attributes are supported, both query and math.

Referencing the __User class #

It is permissible 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 in the editor the following expression: concat(__CurrentUser.firstName,__CurrentUser.lastName).

Reference-predefined-attributes

User Management in the Generated Application #

User management is supported throughout the generated application:

  • In the web client, the item Members management has been removed from the homepage; the management is from now on switched from the menu item related to the _User class that must be present on at least one of the modeled application views. The list of members of the same team is no longer displayed on the homepage;
  • in the Plugin environment, the generated SPI includes the Entity interfaces for managing the _User class as a normal 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.