Set up the Lucca roles - New interface

Before you get started

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 apps 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 rights. A user has only one primary role. In addition, a user must have a primary role. This is a required property.
• The secondary role allows access to additional features in addition to the primary role. A user can have several secondary roles. Secondary roles are generally used to complement the primary role on a specific feature intended for a number of dedicated employees.

In this sheet, we will see how to create a primary or secondary role, then, in a second file, how to assign this role to a user.

 

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 app 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.

We find the following:

• Permission on a formative action at the app level, and/or potentially for several apps
  • 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 of an app's data and jeopardize its operating principles.

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 makes sure of the 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.

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: opening the pay of my departments and the underlying departments, generating 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 jeopardize the hierarchical process

This role is for extracting data on a set scope and compromising 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.

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:
  

 

Access to role management

To access role management, click on the cog wheel at the top right of your navigation bar, then the "Roles" tab:

Easily find an existing role

There are databases with a large number of configured roles. To easily find the one you are looking for, you have three search fields:

1. By role label
2. By employee: for filtering the list of roles according to one or more selected employees.
3. By app: for filtering the list of roles giving access to one or more selected apps

 

 

Create or edit a role

Now that you have accessed the role management, you have two options, if you want:

• Create a role: click on the "add a role" button. You can name the role and indicate whether it is a primary role (as the name suggests, it represents the primary access rights of a user). To recap, a secondary role will simply "complement" a primary role.

• Modify a role: click directly on the relevant role

This takes you to the role settings, as shown in the screenshot below with:

• Three tabs:
  • Permissions: to enable or disable access to the app for this role and manage the read and act permissions inside (see dedicated paragraph, below)
  • Users: to view the users this role has been assigned to, and add new users to this role if necessary (see Help page: Assigning a role to one or more users)
  • Establishments: to manage the scope of this role on one or more establishments (see dedicated paragraph, below)

• The option to view the history of this role (via a hypertext link)
• Hover over the role label to edit the display label of the role
  This is a property that can be entered in several languages, by selecting "Language" in the dedicated selector
• Action buttons with the icons:
  
  • Duplicate: to copy the role
  • Trash: to permanently delete the role (provided there are no users attached)

 

Role permission details

Via the "Permissions" tab, you can open and define:

1. The apps to which you give access to the employees who will have this role. To add permissions, simply click on the relevant application, for example here "Cleemy Expenses"
2. The user permission when they access the app(s), by checking the box next to the operation
3. The scope of the operation.

 

We could also have expanded the scope of the permission to other users. This could be useful if you wanted to set up the role of a manager, department head or administrator, for example. To do this, simply click the "+" displayed to the right of the scope that is already visible and select a new scope to be added.

 

There are different types of access scopes:

- Organizational scopes: to limit the field of action according to the department tree structure, including:

• Department and sub-departments: these are all the employees belonging to the same department as the user with the role, as well as all those who belong to any child departments.
• Department only: all employees belonging to the same department as the user with the role.
• Specific department(s): for designating one or more departments in particular.
• Specific department(s) and sub-department(s): for designating one or more specific departments as well as the underlying departments.
• Departments from level N: these are all the users assigned in the level-N department and its children by positioning themselves at the level of the employee with the role. It is therefore a question, here, of going up the tree structure of the departments from the position of the employee with the role up to the level-N node, and then drawing up the list of all the employees belonging to this branch of the tree structure (i.e. from this node).
  Comment: In the case of a user who is already at a level higher than the number N: the process which draws up the list of employees will be like that in the "Department and sub-departments" case.

- Contextual scopes:

• Manager: this is the manager of the user with the role.
• User: this is the user with the role.
• Supervised employees: these are all the employees whose manager is the user with the role. Convenient for configuring a manager role!
• Employees with the same manager
• Specific user(s)

The resulting scopes for all the operations do not include everything. Indeed, some scopes are not relevant for a given operation.

 

For each permission, the category is shown by a colored icon. It is important to note that in the case of an operation linked to scopes, the category may vary according to the scope. Indeed, in the context of a given operation, an "All departments" scope is likely to be more critical than a "User" scope.  

 

You can combine several scopes of action within a single permission. For example, in the screenshot below, the people in this role can see the details of the absences of their supervised employees as well as their own.
In addition, you will notice that the category displayed at permission level (on the left of the screenshot) corresponds to the highest category of the selected scopes (on the right of the screenshot).

 

Finally, the category is also displayed at the level of the apps assigned to the role. As a result, the level of authorization of a role can be identified for each assigned app.

Limiting the role according to the establishments

You can also limit the scope of all the permissions of a role to one or more establishments. To do this, you must go to the Establishment tab, where you get the following two options:

1. "User establishment": to limit the role to the user's establishment. It is therefore a contextual setting that is tailored to the user.
2. "Attached establishments": to select specific establishments.

Comment: if the "All establishments" option is chosen, there is no need to update the role if a new establishment is created in the future. It will then be automatically taken into account.

In the example below, the users attached to the role will only be able to have an effect on users on the Lucca FR andLucca UK establishments.

Assign the role to a user

Well done, you have created the role! YNow assign it to users as described on the following help page: Assign a role to one or more users.