Before starting
A role is a set of permissions that defines what the user or users to whom it is assigned can see and/or do when they log on to Lucca. This answers the questions: what applications will users with this role have access to? And what will they be able to see and do on it?
The default roles are: "user", "manager" or "administrator", but it is possible to customize others (as many as necessary), e.g. "accountant", "Timmi Absences user only", "company representative" or other, depending on the organization within the company.
In Lucca, there are two types of roles:
- The primary role which represents a user's primary access permissions. A user has only one primary role. A user must have a primary role. This is a required property.
- The secondary role, which provides access to other features in addition to the main role. A user can have several secondary roles. Secondary roles are generally used to supplement the primary role for a specific feature intended for a dedicated number of employees.
This sheet describes how to categorize roles and permissions. If you want to set up your roles, you can find out how to do this in a second sheet: Setting up roles in Lucca.
Role and permission categories
Each role has a category. The category indicates the clearance level of the role.
The role category is not a property that can be set: the category is inherited from the permissions of the role. As a result, the role has the same category as its highest permission.
Consequently, the permissions are sorted into five categories.
From the highest level of authorization to the lowest, the categories are:
Global administrator 🟣
Threat level: can jeopardize a Lucca environment
This is the most critical clearance level and corresponds to a role that potentially allows an instance to be compromised (i.e. damage its overall operations, for all users).
There are permissions for conducting major actions with an impact on the entire instance:
-
Examples: import management, API Key management, authentication management, role administration, installing/uninstalling an app, role management.
Functional administrator🔴
Threat level: Can jeopardize an application and its configuration
The Administrator has read and write access to all the business processes as well as to the configuration resources.
They take action within the framework granted by that the Global administrator.
There we find the following:
- Permission for a structuring action at application level, and/or potentially for several applications
- Examples: managing departments, managing work cycles, managing analytical sections, deleting an accounting nature
- Permission to configure an entire Lucca solution so that it can be put into production:
- Examples: managing the FTPs, configuring the Payroll Assistant connector, managing user data fields in the HR file.
Functional supervisor 🟡
Threat level: can extract almost all data from an application and compromise its functional logic.
The Business manager checks that the business process is properly executed in the app, consolidates the job data for analysis purposes, is the agent of last resort in business processes, and ensures synchronization with external agents.
Examples of "business processes": procedure for validating absences, procedure for validating expense reports, management of review campaigns, etc.
They have extended read access, and write access to business processes within their scope. They must not be able to compromise the use of the app.
They take action within the framework granted by the Business administrator.
There we find the following:
- Permission on a formative action at job level:
- Example: adding an accounting nature, adding a user
- Permission to view confidential data that is specific to the job and/or a wider population:
- Example: View the remuneration of my departments and underlying departments, generate a user report
- Permission to manipulate specific business and/or technical entities.
- Example: checking expense reports, managing campaigns
Manager 🔵
Threat level: can extract data on a set scope and compromise the hierarchical process
This role allows you to extract data from a defined perimeter and compromise the hierarchical process. They are more or less operationally responsible for a subset of users (manager, head of department, director) and for the fulfillment of the business processes modeled in our apps. Consequently:
- They are the main agent of the approval workflows on the requests of the users for which they are responsible.
- They have extended read access to the user resources for which they are responsible.
There we find the following:
- Permissions linked to a hierarchical action:
- Example: approving an absence request for supervised employees.
- Permissions related to the viewing of standard data for an extended population:
- Example: opening the schedule for the supervised employees, opening the goals of the supervised employees, managing the projects of the supervised employees.
User 🟢
Threat level: basic actions within the personal scope
This role is for basic actions on a personal scope.
We find the permissions on basic actions for the standard use of the app: submit an absence for myself, download my payslip, submit my time and my expense reports, etc.
Comments:
- there is actually a 6th category called "No category" which is associated with permissions that cannot be categorized for technical reasons. It serves as an exception.
- A color and iconographic code makes it easy to identify the categories of roles and permissions in the interface: