Access Management

Assigning Roles to a User

Roles can be assigned to a user manually or automatically via program code, as described in the To Data section.

Automatic Assignment

The User_role.sync method exists for automatic synchronization. It will add missing roles from the specified list and remove those not listed. The BASE_ACCESS role, which is required for any user except administrators, will also be added.

Important: This method is suitable if you have only one source for assigning roles. In practice, roles may be assigned from multiple sources or manually. For complex logic, you should write a separate method that collects information from all sources and synchronizes the data without affecting roles unrelated to those sources.

Manual Assignment

You can manually assign a role to a user through the users table by selecting “User Roles” from the context menu.

Role Layering

Multiple roles are layered on top of each other. A user gains access to what is permitted by at least one of their roles, provided it is not prohibited by any of their roles.

Role Configuration

Access settings are stored in the Access -> Access to Operations table. Here, you can add access to a specific operation for a particular role and specify special settings.

Synchronizing the List of Operations

The list of operations is located in the Access -> Class Operations table. To make new classes or methods appear in the list, you must perform synchronization (after developing new functionality). This is done within the table itself via the “Refresh list” context menu.

Access Management Methods

The system has several mechanisms to simplify configuration:

1. Directly adding records to the “Access to Operations” table.
   • You must select the operation, the role, and set the is_access flag.
   • You can grant access to all operations of a class at once by selecting the * operation for that class.
2. Granting access based on denials (via logging).
3. Configuring menu access.

Granting Access Based on Denials

Access denials are logged in the Access -> Access Denials table.

Configuration Algorithm

1. In the Access -> Roles table, set the “Set Access” flag for the role being configured (and uncheck it for the others).
2. Create a test user, assign them the BASE_ACCESS role and the role being configured.
3. Log in to the system as this user (e.g., in incognito mode).
4. Perform the necessary actions. When a denial is received, a record will appear in the “Access Denials” table.
5. Through the “Grant Access” context menu in the denials table, permit the operation for the current role being configured.

Skip No Access Mode

To avoid switching between windows after every denial, you can activate a mode where denials are only logged, but the operation executes successfully.

To activate:

1. Add the user’s id to the enableSkipNoAccessForUsers parameter array in the config/config.json configuration file.
2. Restart the main server process.
3. Go through the functionality in bulk, and then grant access in bulk for all recorded denials.

Menu Access

To grant access to menu items:

1. Select the role for configuration (“Set Access” flag in the roles table).
2. Go to the System -> Menu Editor table.
3. Find the desired items and select “Grant Access” from the context menu.

Configuring Access with Inheritance

If access to an operation should be restricted to specific records (by list), the following settings in Access_to_operation are used:

Hierarchical List-Based Access

To provide access only to records specified in the Access List:

• Set the is_access and is_access_by_list flags.
• To have access automatically propagate to child records of the same class, add the self_hierarchical flag.

Access Inheritance for Child Entities

To have access to a parent entity (e.g., Project) grant access to a child entity (e.g., Project Pictures), you need to create an access record for the child entity and link it to the parent:

1. Create an access record for the child operation (e.g., project_picture.get).
2. Set the is_access and is_access_by_list flags.
3. In the Parent name field, select the parent operation (e.g., project.get).
4. In the parent_foreign_key field, specify the name of the field in the child table that refers to the parent (e.g., project_id).

If the child entities themselves have a hierarchy, hierarchical access can also be configured for them.