Hi,
Yes, you can prevent user from accessing fields by using ACL.
ACL-Access control list
An instance uses access control list (ACL) rules, also called access control rules, to control what data users can access and how they can access it. ACL rules require users to pass a set of requirements in order to gain access to particular data. Each ACL rule specifies:
- The object and operation being secured
- The permissions required to access the object
Granting or Denying Access
When a user attempts to access a particular object, the system searches for ACL rules that match the requested object's type, operation, and name. If an ACL rule matches these elements, then the user must meet the permissions described in this rule to access the secured object.
If the user fails to meet the permissions required by the first rule, the system searches for the next matching ACL rule. For each matching ACL rule, the user has a chance to meet the required permissions in order to access the object. The system stops searching for matching ACL rules if the user ever meets a matching ACL rule's permissions. If the user cannot meet the permissions of any matching ACL rules, the system denies the user access to the object.
The effects of being denied access to an object depend on the ACL rule that the user failed. For example, failing a read operation ACL rule prevents the user from seeing the object. Depending on the object secured, the ACL rule could hide a field on a form, hide rows from a list, or prevent a user from accessing a particular UI page. See the table for a complete list of results of failing an ACL rule for a given operation and object type.
| Operation | Results of Failing an ACL Rule on Object |
|---|---|
| execute | User cannot execute scripts on record or UI page. |
| create | User cannot see the New UI action from forms. The user also cannot insert records into a table using API protocols such as web services. Note that a create ACL with a condition that a field contain a specific value always evaluates as false, as fields on new records are considered empty until saved. |
| read | User cannot see the object in forms or lists. The user also cannot retrieve records using API protocols such as web services. |
| write | User sees a read-only field in forms and lists, and the user cannot update records using API protocols such as web services. |
| delete | User cannot see the Delete UI action from forms. The user also cannot remove records from a table using API protocols such as web services. |
| edit_task_relations | User cannot define relationships between task tables. |
| edit_ci_relations | User cannot define relationships between Configuration Item [cmdb_ci] tables. |
| save_as_template | Used to control the fields that should be saved when a template is created. |
| add_to_list | User cannot view or personalize specific columns in the list mechanic. |
| list_edit | User cannot update records (rows) from a list. |
| report_on | User cannot create reports on the object. |
| personalize_choices | User cannot right-click a choice list field and select Configure Choices (Personalize Choices in versions prior to Fuji). |
Process order for record ACL rules
Record ACL rules are processed in a certain order.
Record ACL rules are processed in the following order:
- Match the object against field ACL rules.
- Match the object against table ACL rules.
- If a user fails a field ACL rule but passes a table ACL rule, the user is denied access to the field described by the field ACL rule.
- If a user fails a table ACL rule, the user is denied access to all fields in the table even if the user previously passed a field ACL rule.
If my answer helped you in any way, mark answer as helpful and correct.
Thanks and regards,
Megha.
