Configuration of access to the application with the use of profiles

The document describes the management of access to system functions based on a definable list of permissions.

Purpose: to provide users with a separate part of the system to work only on the scope assigned to them. The rest of the system should be invisible to the user. According to the employee’s work profile and position, the user should have different permissions within each module to moderate the mechanism of creating/modifying/deleting objects in the system.

For example:

Access profiles in the configuration section allow you to define a set of permissions that are grouped under such a profile. This allows you to name some roles/functions in your organization and then define the list of permissions that role has in the system.

The list of access profiles is in the configuration view. To add a new profile, we use the (+) action available in the main menu.

We define each access profile with a name and a brief description of what it is related to. That makes it easier to check these functions later.

After adding the general framework of permissions, we get a list of them. The Functions column contains the number 0, which means that no functions are enabled for that access profile.

In the detailed profile options, we specify access to individual system modules. Each module has its own list of permission functions. The main functions are based on: accessing data, creating a new type of a given object, editing existing objects, and deleting an object.

Depending on the module, it may have additional detailed permissions, which are a division of the above-mentioned general procedures (read, write, edit, etc.) into detailed operations, e.g., changing the state of an object. That is allowed by the precise definition of permissions.

Using the Check/Deselect buttons, we can check/uncheck all functions in a given module.

Each AMAGE instance has its own defined list of available modules. The list of modules in the profile list also changes accordingly, displaying functions/permissions from active modules only.

After defining the related permissions, you get a list of access profiles with the functions and their access filled in. The number of permissions active for a given profile is shown in the Functions column

Note that in addition to access profiles for users, we can define access to a selected section of the system. We define it for each user in their definition and Access tab.

Under this section, we define access permissions to the mobile, desktop, and configuration parts. With this division, we can specify access to the mobile part for line employees (only those who register work).

There is an additional "Super-Administrator" permission flag in the user definitions. It was introduced in order to skip checking access profiles. We define it in the access of each user.

By default, when a user is added to the system, they have no permissions, and the system would not allow them to do any work. In this case, assigning the super-administrator flag to the initial (main) user of the system allows access to the entire system interface without any initial definition of permissions.

The easiest way to test the privilege profiles is to use an additional test user and use the function of modern web browsers to work in incognito mode. That allows you to open two browser windows and log in as two different people to the system.

We define access for the test user according to the (sample) list of access to sections of the system.

Go to the list of profiles of a particular user.

We give it new access permissions by selecting access profiles.

During testing, if a user does not have permission to a particular section/action, a message will appear about the lack of detailed permissions.

User data importers have the ability to specify the access profiles to which a user is to be assigned. That allows you to automate access during the user import procedure. For more on this, see the integration/import and export information.