Required Roles
Depending on what role a user is assigned in Atoti Limits, they have different permissions and can carry out different tasks. This page outlines the required roles in the module.
ROLE_LIMITS
This role is required. Atoti Limits creates the KPI (Key Performance Indicator) in the business Cube after the limit definition is in the Approved status. ROLE_LIMITS is the default KPI owners and readers. KPIs are tagged with owner ROLE_LIMITS, so they can be distinguished from other KPIs created by other applications. The module deletes the KPIs by ROLE_LIMITS in the content server during startup, before consuming the initial load limit files.
Any user who has access to Atoti Limits needs to be set up as ROLE_LIMITS, otherwise they can’t see the KPIs in the business cubes created by the module.
ROLE_USER
This role is required. Atoti Limits creates the KPI (Key Performance Indicator) in the business Cube after the limit definition is in the Approved status. ROLE_USER is the default KPI owners and readers.
ROLE_USERS
Group of ROLE_USER.
This role is used by BPMN in Activiti. In the reference workflow implementation, ROLE_USERS can initiate the Straight-through and 4-eye workflows.
The value in the activiti:candidateStarterGroups tag is parsed in the module to map to ROLE_USERS.
For example, in the 4-eye BPMN file, USERS can start the workflow process. Atoti Limits checks if the current user is ROLE_USERS.
<activiti:candidateStarterGroups="USERS">
ROLE_MANAGERS
Group of ROLE_MANAGER.
note
ROLE_MANAGER is not used explicitly in the module, but it’s used by BPMN in Activiti.
This role is used by BPMN in Activiti.
The Activiti security user “MANAGERS” is parsed in the module to map to ROLE_MANAGERS.
<activiti:candidateStarterGroups="MANAGERS">
ROLE_ADMIN
The user with ROLE_ADMIN is able to access the RESTful endpoints or to issue the web service against the Atoti Server instances.
In the reference workflow implementation, ROLE_ADMIN can trigger the limit evaluation RESTful endpoint and the DLC.
ROLE_ACTIVITI_USER
The user with ROLE_ACTIVITI_USER is able to access the Activiti queries.
ROLE_ACTIVITI_ADMIN
A user with ROLE_ACTIVITI_ADMIN can update the process definition in Activiti at runtime. Currently, the reference workflow implementation doesn’t provide this functionality.
Default Users
| Default user | Role | Create/update/delete | Upload file | Approve limit change/deletion |
|---|---|---|---|---|
| user1/user1 | ROLE_USER GROUP_USERS ROLE_ACTIVITI_USER ROLE_CS_ROOT |
|||
| manager1/manager1 | ROLE_USER GROUP_MANAGERS ROLE_ACTIVITI_USER ROLE_CS_ROOT |
|||
| manager2/manager2 | ROLE_USER GROUP_MANAGERS ROLE_ACTIVITI_USER |
|||
| admin/admin | ROLE_ADMIN ROLE_CS_ROOT GROUP_USERS GROUP_MANAGERS ROLE_USER ROLE_ACTIVITI_USER ROLE_ACTIVITI_ADMIN |
APPROVERS and EXAMINERS
Depending on the type of workflow defined on the Limit Structure, the following types of users can approve/reject a limit:
Four-eyes workflow
The APPROVER user can approve or reject the limit.
Note that ROLE_MANAGERS can always approve/reject four-eyes workflows.
Six-eyes workflow
The EXAMINER user can make the first approval/rejection of the limit.
The APPROVER user can make the second and final approval/rejection of the limit.