6.2.3. Permissions

Permissions determine the user’s right to application objects and functions, such as UI screens or entity operations. With regards to permissions, these objects are called targets.

Permissions are granted to users by assigning roles to them.

Users have no rights to a target, unless an appropriate permission is given to them by a role. So users without roles have no any rights and cannot access the system through the Generic UI and REST API.

There are the following types of permissions differentiated by targets:

Screen permissions

A screen can be either allowed or denied.

The screen permissions are checked by the framework when building the main menu and creating screens using the create() method of the Screens interface. To check screen permissions in the application code, use the isScreenPermitted() method of the Security interface.

Entity operation permissions

For each entity, the following permissions can be allowed: Create, Read, Update, Delete.

See the Data Access Checks section for how entity operation permissions are used by different mechanisms of the framework. To check entity operation permissions in the application code, use the isEntityOpPermitted() method of the Security interface.

Entity attribute permissions

Each attribute of each entity can be allowed for viewing or for modification.

See the Data Access Checks section for how entity attribute permissions are used by different mechanisms of the framework. To check entity attribute permissions in the application code, use the isEntityAttrPermitted() method of the Security interface.

Specific permissions

These are permissions on arbitrary named functionality. Specific permissions for the project are set in the permissions.xml configuration file.

An example of checking a specific permission :

@Inject
private Security security;

public void calculateBalance() {
    if (!security.isSpecificPermitted("myapp.calculateBalance"))
        return;
    // ...
}
Screen component permissions

Screen component permissions allow you to hide or make read-only particular UI components of a screen, regardless of whether they are bound to entities or not. Screen component permissions are applied by the framework after sending AfterInitEvent and before BeforeShowEvent.

The screen component permissions differ from other permission types in that they actually only restrict rights to their targets. Until you define a target component and a hidden/read-only permission for it, the component is fully available to the user.

The target component is specified by its path in the screen according to the following rules:

  • If the component belongs to the screen, simply specify the component identifier.

  • If the component belongs to the fragment that is embedded within the screen, specify the fragment identifier, and then the component identifier separated by period.

  • If configuring permission for the TabSheet tab or the Form field, specify the component identifier, and then the tab or field identifier in square brackets.

  • To configure permission for an action, specify the component, holding the action, and then the action identifier in angle brackets. For example: customersTable<changeGrade>.