Configuration of access to the application with the use of profiles
Introduction
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.
The default is that when you create a user who is not a super-administrator (explained later), such a user has NO permissions. That means that after logging in, they will only see a blank system screen without access to any functions except logout. |
For example:
-
we want all users to have access to general functions in the system, such as password change, feature list, and mobile and desktop view
-
we want to define a set of permissions for warehouse employees so that they can only work on sections related to warehouse turnover and delivery/order procedures
-
among these employees (warehouse), we want to separate administrative employees (who formally manage the warehouse) and line employees (who are involved in issuing/receiving physically in the warehouse)
-
We want to have employees only registering work for work orders
-
We want to have employees managing work orders with full access to reporting
-
We want to be able to test all of this before assigning permissions to employees.
Access profiles
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.
A user in the system can have multiple access profiles. Their permissions in such a case are the SUM of the permissions from each of the access profiles assigned to them. That allows you to divide permissions into profiles and then add/remove such profiles from the current list. That way, you can divide permissions into manageable areas and assign employees (to each individual) the appropriate ranges of access to system functions. |
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.
In the list of modules, a number appears in round brackets, which shows the number of selected (active) permissions of a given module. This makes it easier to see which functions from the modules in a given profile are activated. |
If you change the list of modules in an instance (adding functionality), it is required to specify access for new modules. By default, the permissions in such a case are reset to zero. |
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
System sections
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).
The definition of section access is an additional definition of where a particular user works in the system (e.g., only in the mobile-simplified interface). That allows separate access to such data also for subcontractors, etc. |
Super-Administrator
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.
Do not overuse the super-administrator flag for all users. It allows unrestricted access to the system. |
Testing
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.
The system saves the login session data in the browser’s memory after logging on the browser. This allows you to open subsequent application windows (browser tabs) without having to log into the system each time. Unfortunately, this does not allow you to log in to several accounts simultaneously in such a case. Incognito mode separates such a session and allows parallel work. |
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.
Automation
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.
The Howto is based on system version 1.17.0.14(07.2022) and presents features that may not be available in your system. Ask AMAGE about making this functionality available. |
Due to the ongoing development of the system, some screens or configuration files may look slightly different, but will still retain the full functionality described here. This does not affect the essential functions described in this document. |