The ACL rules allow you to secure access to the objects and operations, depending on your business processes.
For example, you can restrict changing states of a task to the users who are not involved in the process (editing is available only to the assigned user).
The ACL check is performed using three fields combined:
If the Roles field of the ACL rule is empty, the next step is the condition check, if any specific condition is specified. If the Condition field is empty, then the Script field checks for the specific conditions and attributes. If any of these steps fail, the ACL check fails, too. That is, ACL does not check the next steps if the previous fails. The scheme below represents the ACL check process: |
Role required: security_admin. Elevate your privileges to this role to create or perform any other operations with ACL rules. |
To create an ACL rule, complete the following steps:
Access Control form fields
Field | Mandatory | Description | |||||
---|---|---|---|---|---|---|---|
Name | Y | This field is read-only and is populated automatically by the system after saving the record. The word in the square brackets indicates the operation. The name after the first period indicates the secured table and the column (if there is one specified in the Column field): [Delete].sys_history [Read].sys_history.created_by
| |||||
Operation | Y | Select an operation to secure. Available options:
| |||||
Any tables | N | Select this checkbox to secure all tables in the system. | |||||
Table | Y | Specify a table to secure.
| |||||
Description | N | Add a description of the ACL rule. | |||||
Roles | N | Specify the roles required to pass the ACL check. After a role is specified, users without this role do not pass the check. You can select more than one role. | |||||
Active | N | Select this checkbox to activate the ACL rule. | |||||
Admin overrides | N | Select this checkbox to allow system administrators (users with the admin role) to pass the ACL rule. Admin users access the object or operation regardless of the existing restrictions. Clear this checkbox to check users by the rule. Define the filters in the condition builder or in the Script field to create conditions that admin users should meet to get access. | |||||
Any fields | N | Select this checkbox to secure all columns in the table. | |||||
Column | N | Select a column to secure.
| |||||
Condition | N | Use the condition builder to create filters. | |||||
Script | N | Enter a script that defines the conditions to meet. The result of the script execution is the answer variable equal to true or false. If the script is not added or the answer variable is not set, the default value of the variable is true.
|
Case 1 The company should hide the following information about its employees:
Only the users with the user_manager and admin roles and the employee themselves should have access rights to this information. An employee cannot see the mobile phone and roles of other employees. |
To do so, you need to set up two ACL rules:
|
The result is the following:
These two screenshots illustrate the Employee list with ACLs №1 and №2.
|
Case 2: You need to allow access only to one field in the Request (itsm_request) table, but creating an ACL for each field you need to protect to is time-consuming. For these purposes, you need to create two ACLs:
Let us consider the differences between them. |
|
These ACL rules ensure that the caller (or any other user who is not an agent) cannot edit the record fields. Only users with ITSM_agent and admin roles can do that. At the same time, the caller can leave comments to communicate with the assigned user or group. In other words, the ACL rule marked with the asterisk (*) works for each field, except those that have their own ACL rules. |