Notifications

5 views

Description

When a field level read ACL is created, in most cases the ACL framework will automatically create a table.* ACL to cover the rest of the fields on that table.

The table.* ACL is created by copying the first table level ACL that is found when querying for them, and then assigning any Roles to it that are just associated to that found ACL.

You can run the following code to find out which ACL this would be in a particular instance:

var gr = new GlideRecord("sys_security_acl");
gr.addQuery("name",<enter affected table name here>);
gr.addQuery("operation","read");
gr.addActiveQuery();
gr.query();

if(gr.next()){
gs.print(gr.sys_id);
}

This means that any other table level ACLs that might exist, that could have other Roles and Conditions associated, will not be accounted for in the newly created table.* ACL.

This can then result in unexpected visibility issues in the UI.

Cause

This ACL auto-creation feature was originally introduced to help customers transition from an older security manager implementation to the current one.

This feature is not necessary with the current security manager implementation, and is being disabled for new instances.

Resolution

This behaviour has been raised and addressed in PRB1263737, a fix for which is available as of New York Patch 3.

Article Information

Last Updated:2019-11-21 03:31:20
Published:2019-11-21