ACL debugging tools Field level debugging and access ACL rule output messages are available to help you troubleshoot and debug ACLs. The ACL configuration watcher lets you know what related ACLs exist when you modify one. Field level debugging When debugging is enabled, a small bug icon () appears beside each field with an ACL rule. Clicking the icon lists the ACL rules that apply for the field and the evaluation results. Figure 1. Field level security on an incident After enabling ACL debugging, you can impersonate another user to see what ACL rules the user passes and fails. When you impersonate a user, you can only see what that user is allowed to see. For example, you cannot view a record that an ACL prevents the user from seeing. To make debugging easier, read-only access to certain ACL-related tables is enabled by default, even when impersonating a user that does not have read access to the tables. To change this functionality, set the following property to false. To enable ACL rule debugging, navigate to System Security > Debug Security Rules. System property Description Default setting glide.security.access_acl_as_impersonator Allows read access to the following tables while impersonating a user: sys_security_acl, sys_security_operation, sys_security_type, and sys_user_role. As a result, the impersonating user can read data that the impersonated user cannot read. trueNote: When the property is set to false, the impersonated user might be prevented from reading ACL-related data. In this case, a second session logged in as admin or security_admin might be required to debug ACLs. ACL rule output messages ACL debugging displays ACL rule output messages at the bottom of each list and form. The output message displays the following: Message element Description TIME The total time used to process this ACL rule. PATH Information that uniquely identifies each ACL rule in the format: <ACL rule type>/<ACL rule name>/<Operation>. CONTEXT The object being evaluated by the ACL rule. RC The return code of the ACL rule. A true value passes the ACL rule. A false value fails the ACL rule. RULE A brief summary of processors and scripts, followed by ACL results for each table-level and field-level ACL evaluation. Most ACL evaluations show an overall pass or fail result followed by a breakdown of the results for each type of ACL criteria: iAccessHandler: An internal system check using hidden source code on the platform. This is a system security check that you cannot modify. IAccessHandler can grant or deny access to a resource without evaluating ACLs. If IAccessHandler is ignored, then the ACLs are evaluated. You cannot modify the IAccessHandler checks in any way. For example, an IAccessHandler implementation is used for access checks on application resources and this cannot be changed. This is available starting with the Istanbul release. Roles: Verification that the user has the correct role. Condition: Verification that the user passed the condition specified on the ACL rule (if any). Script: Verification that the user passed the script specified on the ACL rule (if any). The icons that appear show how the ACL was evaluated: Icon Description A green checkmark () Indicates the table or field passed the criteria. A red x icon () Indicates the table or field did not pass. An empty gray circle icon () Indicates the ACL evaluation did not need to be performed. A blue checkmark, x, or empty circle Indicates that the ACL was taken from a cached result of a previous ACL check. The icons mean the same as the above. You can perform these actions on the ACL debug output: Select or clear these check boxes at the top of the debug output: Security rules: Show or hide the results of the ACL checks. Others: Show or hide other warnings or messages. Click the name of the ACL next to any of the output messages to open that ACL record. Hover the cursor over any of the icons for the four ACL checks to see more information. ACL troubleshooting reference Common ACL rule errors and their solutions. Error or symptom Solution You cannot access records from a custom table. Create a table ACL rule for the custom table granting users access to the table. Without an explicit table ACL rule, users must pass the permissions in the table wildcard (*) ACL rule, which by default restricts access to administrators only. Enable debugging and determine what ACL rules are evaluated for the custom table. You create a custom ACL rule that does not work properly. The most likely problems are that another rule takes precedence over your custom rule in the processing order or that the user does not meet all the permission requirements for the object type. Enable debugging and verify that the ACL rule is being evaluated. Your field ACL rule does not work properly. There is likely a table ACL rule that the user has not met. Enable debugging and determine what ACL rules are evaluated for the field. Verify that there is not a conflicting table ACL rule or duplicate field ACL rule. Your table ACL rule does not work properly. There is either an ACL rule higher in the processing order or a duplicate table ACL rule interfering with the table ACL rule. Enable debugging and determine what ACL rules are evaluated for the table. You can see a field in a list but not in form. It is possible that the ACL rule conditions or script are being triggered in the list but not in the form. Enable debugging and determine when the ACL rules evaluate to true. Update the conditions or script to have the same behavior on the list and form. You receive an error message when trying to execute a processor or client-callable script include. There is an ACL rule for the processor or client-callable script include that the user has not met. If the user should have access to the object, enable debugging and determine what ACL rules are evaluated for the processor or script include. Update the ACL rule or the user roles as needed to access the object. ACL configuration watcherThe ACL configuration watcher lets you know what related ACLs exist on a table when you insert, update, or delete an ACL on the same table.