Versions Compared

Old Version 2

changes.mady.by.user Dina Baksheeva

Saved on

compared with

New Version Current

changes.mady.by.user Dina Baksheeva

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Merged branch "DOC0001266" into parent

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 assignee). In the Use case section of this article, consider the following case: you need to hide specific information about employees so that the confidential information and information about their roles are protected in the system.assigned user).

Info

The ACL check is performed using three fields combined:

  1. Roles
  2. Condition
  3. Script

If the Roles field of the ACL rule is empty, the next step is the condition check, if any specific condition was is specified. If the Condition field is empty, then the Script field is to check 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:

Image RemovedImage Added

Create an ACL rule

Tip

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:

  1. Navigate to the System Security → Access Control (ACL).
  2. Click New and fill in the fields.
  3. Click Save or Save and Exitexit to apply the changes.

Access Control form fields

FieldMandatoryDescription
NameY

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)

after another period

:

[Delete].sys_history

[Read].sys_history.created_by

Info

This field supports the asterisk (*) wildcard character in place of a record, table, or field name, which allows selecting all objects matching a record type, all tables, or all fields

.A wildcard character and a text search cannot be combined

.

Good

problem.*

*.task

Badpro*



OperationY

Select

the

an operation to secure. Available options:

  • create
  • read
  • write
  • delete
Info

One ACL rule can secure only one operation. To secure more than one operation, create a separate ACL rule for each of them.


Any
Tables
tablesNSelect this checkbox to secure all tables in the system.
When selected, the Table field is hidden until it is cleared.
TableY

Specify a table to secure.

Info

One ACL rule can secure only one table. To secure several tables, create a separate ACL rule for each of them.


DescriptionN
Enter
Add a description of the
object or permissions this
ACL rule
secures
.
RolesN

Specify the roles required to pass the ACL check. After

the

a role is specified, users without this role do not pass the check.

You can select more than one

role. InfoRoles are chosen out of the Roles (sys_

role

) dictionary

.

ActiveNSelect this checkbox to activate the ACL rule.
Admin
Overrides
overridesN

Select this checkbox to allow system administrators (users with the admin role) to pass the ACL rule

automatically

. Admin users

will

access the object or operation regardless of the existing restrictions.

Clear this checkbox to check

these

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
fieldsNSelect this checkbox to secure all columns in the
system. When checked, the Column field will be hidden until cleared
table.
ColumnN

Select a column to secure.

Info

One ACL rule can secure only one column. If you need to secure more than one column, create a separate ACL rule for each of them.


ConditionN

Use the condition builder to create filters.

ScriptN

Enter

the

a script that defines the conditions to meet. The result of the script execution

result

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.

Info

If you pass any non-Boolean value to the answer variable, it is implicitly converted to the Boolean type.

Code Block
languagejs
themeEclipse
titleExample
linenumberstrue
answer = current.sys_id;
// if the record already exists - true, if there is no record yet (null) - false


Use case 
Anchor
ACL user case
ACL user case

Panel
borderStylesolid

Case 1

The company should hide the following information about its employees:

    • Mobile Phonephone
    • User Rolesroles

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 thisso, you need to set up two ACL rules:

Section
bordertrue


Column
width50%

ACL №1 allows access to the Mobile Phone field to the record owner:

FieldValue
Operationread
Admin Overridestrue
TableEmployee
ColumnMobile Phonephone
Condition

ID is javascript: return ss.getUserID();


The ACL rule is created: [Read].employee.mobile_phone


Column
width50%

ACL №2 allows access to the Mobile Phone field to user managers:

FieldValue
Operationread
Admin Overridestrue
TableEmployee
ColumnMobile Phonephone
Rolesuser_manager

The ACL rule is created: [Read].employee.mobile_phone


The result is the following:

Section
bordertrue

These two screenshots illustrate the Employee list with ACLs №1 and №2.

Column
width50%

The list of records shown to the owner of the employee record without the user_manager role (Stepan Petrov):

Image Modified


Column
width50%

The list of records shown to a user with the user_manager role:

Image Modified



Panel

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:

    • [Write].itsm_request.additional_comments – gives access to edit the Additional Commentscomments field.
    • [Write].itsm_request.* – restricts access to all fields to users without the ITSM agent role. The restriction works for each field for which there are no allowing ACL rules.

Let us consider the differences between them.


Section
bordertrue


column
Column
width50%

Since this ACL rule does not specify roles and conditions, it is the allowing ACL rule.

[Write].itsm_request.additional_comments

FieldValue
Operationwrite
Admin Overridestrue
TableRequest
Any Fieldsfalse
ColumnAdditional Comments
comments



Column
width50%

This rule allows the users with ITSM_agent role to edit all fields in the Requests table. Users without this role have no access to edit all fields of the Requests table.

[Write].itsm_request.*

FieldValue
Operationwrite
Admin Overridestrue
TableRequest
Any Fieldstrue
RolesITSM_agent




Section

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 which that have their own ACL rules.


Table of Contents
absoluteUrltrue
classfixedPosition
printablefalse