Management of rights

The assignment layers

When the system decides whether or not to validate a user's action, the various access rights are consulted at all levels. Here are some possible combinations:

1. Group.

2. Group → Group role.

3. User → Group → Group role.

4. User → User role → Group → Group role.

A rights assignment layer is a point of attachment, linked to a user, which enables a set of access rights to be grouped together.

There are 3 assignment layers assigned to:

• The user himself.

• User groups.

• Roles.

• Permissions included in the roles.

These three assignment layers interact in the following way:

• A user can belong to a single group and have several roles.

• A group can have several roles.

These layers simplify the organisation of the different access rights available to a user and are therefore not governed by priorities. When the system decides whether or not to validate a user's action, the different access rights are consulted at all levels.

Permission management

Access: Administration → User management → Permissions / Meta permissions

There are 3 families of access rights:

1. Permissions: a permission is the permission that is attached to an object (Access: Administration → User management → Permissions). In this menu, you will find the list of all the permissions that are available in the application. Each permission is attached to a object (object in the application). You will have associated authorisations (read / write / create / remove / export).

• Read: the user has the right to read the record.

• Write: the user has the right to modify the record.

• Create: the user has the right to create a record.

• Remove: the user has the right to delete the record.

• Export: the user has the right to export the record.

2. Permissions by field (Meta permissions);

3. Permissions on menus.

Each of these families uses one or more authorisations from the following five authorisations (‘Allow’ sections):

• Read ;

• Modify ;

• Create ;

• Remove :

• Export.

Here you can also define conditions and parameters in JPQL (for example, to filter sales orders only on the list of companies that were defined in the user file).

Permissions by field: permissions by field will allow to have more precision when working on an object. They are interpreted at both client (browser) and server levels. Within an object, it is possible to grant rights only to certain fields. For example, you can give the right to modify certain information relating to a customer (telephone number, email, etc.) without authorising the modification of other fields (such as the customer's name).

In the following example, you will find permissions per field on the SaleOrder object. This Meta Permission will then be added to a role.

The principle is similar to that of permissions. You must indicate a name and the reference of the object for which you wish to define new permissions.

Meta permissions: the rule table then allows you to specify a rule for each field (using its technical name) that will replace the general rule on the object.

It is possible to add two conditions:

1. Read only if: to make the element read only if the condition is true.

2. Hidden if: hides the element if the condition is true.

• Conditions:

It is possible to assign a condition to a permission, so that the permission will only be valid if this condition is verified.

Writing a condition: conditions are written in JPQL and can refer to one or more parameters. The ‘?’ sign must be used every time a parameter is to be called. A new parameter must be defined for each ‘?’ sign in the condition.

For example: self.user = ? AND self.company = ? will necessarily be accompanied by 2 parameters separated by a comma.

In this example, if the user who is a part of the company (condition: self.company.id in (?) with the parameter _user_companySet.id.plus(0) ), will be able to read, modify and create a record.

• Parameters:

Separate the parameters with a comma, each parameter corresponds to a ‘?’ in the condition expression, in chronological order. It is necessary to repeat the same parameter several times if it corresponds to several ‘?’ signs in the condition.

The following parameters are authorised:

User: the connected user ;

Date: the current date ;

Time: the current time ;

Datetime: the date/time of the day.

It is possible to use an expression on the connected user, using ‘.’ to separate field names (technical name).

Example: user.activeCompany.id: represents the id of the company linked to the user.

Meta permissions

Access: Administration → User management → Meta Permissions

Meta Permissions (permissions by field), like simple permissions, are permissions that apply not only to an object, but to all the fields of an object.

Permissions by field allow you to work more precisely on an object. They are interpreted at both the client (browser) and server level. Within an object, it is possible to grant rights to certain fields only. For example, you can give the right to modify certain information relating to a customer (telephone number, email, etc.) without authorising the modification of other fields (such as the customer's name).

In the following example, you will find permissions per field on the SaleOrder object. This Meta Permission will then be added to a role.

Create a new meta permission

Access: Administration → User management → Meta Permissions → click on +

1. Name: enter the name. For example, SaleOrder.

2. Object: enter an object. For example, com.axelor.apps.sale.db.SaleOrder.

tip

Copy the object name to use it in the object field on the meta permission form.

3. Rules: in the Rules table, select a field and define the authorisation for this field (Read / Write / Export). By default, if the user has access to an object (i.e. an object), they will have access to all fields (read/modify/export). Permissions per field are permissions that give the right to read a field. For example, you can read the field without having the right to modify it.

4. Field: in the Rules table, copy/enter the technical name of a field in order to add it to the ‘Field’ column. For example, in the ‘Field’ column, enter the technical name of the Company.

5. Read: if you want the Company field to be read-only, check the ‘Read’ box. If you attach this permission to a role, or to a user directly, or even to a group of users. The user who has access to this group or to this role, or directly to this permission, will only have read-only access to the field indicated in the ‘Rules’ table.

6. Attach permission: then attach the permission to a group. Access: Administration → User management → Roles → in the list of roles, select a role, for example, Sale User.

7. Permissions (fields): in the ‘Permissions (fields)’ table, add a field by clicking on +. For example, add the ‘SaleOrder’ field to which you have applied the Meta permission (the Company field is read-only).

tip

Permissions can be applied to fields, but also to buttons.

For example, a user may have access to create, read and modify a Sale Order (customer quote/order), however if the configuration has been made, he will only have read-only access to the validation of the quotation (i.e. the validation button).

Note that in order to do this, you must first configure the Meta permission.

Permissions assistant

Permissions are generally defined in groups. This is because creating permissions manually by field for each element of an object view can be time consuming.

You can find this menu in : Administration → User management → Permissions assistant.

An assistant is available to automatically generate permissions.

The assistant will allow you to select several groups (all the groups for which you want to manage permissions) as well as the different objects to be managed.

Create file: a ‘Create file’ button allows you to generate a file that you will have to complete manually.

In the first line of this document you will find the names of the selected groups.

In the second line are the names of the columns, which are:

1. Object: the name with the package of the selected objects.

2. Field: the name of the field.

3. Title: the title of the field in French.

7 columns repeated for each group:

1. Read: allows you to visualise the element/object.

2. Write: allows you to modify the element/object.

3. Create: only for the object.

4. Remove: only for the object.

5. Export: allows you to export the element/object.

6. Read only if: as seen previously for the element.

7. Hide if: as seen previously for the element.

You must then enter an ‘x’ in each box of the table according to the permissions you are looking for (except for ‘Read only if’ and ‘Hide if’ where you must enter a condition, i.e. a character string).

Example: on the Purchase and Accounting group, only on the PurchaseOrder object. Once the file is complete, simply return to where it was generated and import it in place of the old one, then click on the ‘Import permissions’ button to create the permissions in the different groups.

Only the fields of an object are automatically added when the file is generated. To manage the permissions on the other elements of a view, such as buttons, you must manually add a line in the file with the name of the button in the ‘Field’ column (the title can be added in the ‘Title’ column, but this is only information for the user filling in the file).

caution

Note that this line must be added in the same place as the subject fields and not at the end of the file.

It will automatically generate permissions. These permissions are associated with groups.

Permission assistant: practical case

Access: Administration → User management → Permission assistant

This assistant allows you to automatically create permissions and link them to roles.

info

Before you open the permission assistant, create roles beforehand.

Create a role: remember to create a role for the ‘Helpdesk’ module.

Access: Administration → User management → Roles

For example, the following roles have been created:

• Helpdesk (Read only)

• Helpdesk (Manager)

• Helpdesk (Technician)

info

The ‘Helpdesk’ module consists of ticket management. In a ticket, you will find the name of an object (object). On the form, you will find several fields: fields that are linked to the Help Desk module, and other fields that refer to objects that are linked to other modules.

For example, the Customer field is linked to q Partner object, which is part of the Base module. The Project field is part of the Project module, etc.

1. Permission assistant: next, open the permission assistant.

2. Type: select the ‘Roles’ type.

3. Roles: in the ‘Roles’ table, select the roles that you created previously (in the example, it is ‘Helpdesk - Read Only’, ‘Helpdesk - Manager’, ‘Helpdesk - Technician’). The Roles table will appear.

4. Objects: select all objects that are linked to your module (for example, HelpDesk objects, such as Ticket / TicketStatus / TicketType etc).

5. Language: select the language.

6. Create file: click on the ‘Create file’ button to create a CSV file.

• Open the file and make changes.

• In the file, you will find a line for each concerned object.

• You will see that there is a grouping by role (Read / Write / Create / Remove / Export).

• You will also find Conditions.

• Role by role, give permissions. For example, for the role ‘Helpdesk (Read Only)’, in the ‘Read’ column, mark each object (object) with a cross (x) to confirm that this object is available in Read Only mode only.

• For the ‘Helpdesk (Manager)’ role, all permissions have been given (Read / Write / Create / Delete / Export). In this way, a manager will have full access.

• For the ‘Helpdesk (Technician)’ role, give Read permission for all objects, and give modify (Write) permission for only one object (Ticket).

• You can also add conditions. For example, enter a condition to indicate that a Technician has the right to modify the tickets assigned to him.

• Save the changes that have been made.

8. File: download the CSV file you have just modified by clicking on the icon.

9. Import permissions: click on the ‘Import permissions’ button to import the permissions. Refresh the page for the information to appear on the Role form.

caution

Remember to download the CSV file before starting to import the permissions.

10. Rôle: open the Rôle form. The ‘Permission’ table will be filled in. You can view each permission by clicking on its file.