How do you Implement Complex ACLs?

[Richard101]

I was reviewing some of our ACLs and was thinking if there was a benefit in splitting them up. For example, here is the script on one on our Change ACLs:

answer = false;

if(gs.getUser().hasRole('change_manager') || gs.getUser().hasRole('u_change_admin')){

answer= true;

}

if(current.state == -5 && (gs.getUserID() == current.opened_by || gs.getUserID() == current.requested_by)){

answer= true;

}

This ACL does not take advantage of the OOB roles and condition fields. So, my idea was to see how many ACLs I can convert(and split up) so that they only use the roles and condition field. AKA never have an advanced ACL. Obviously, this wouldn't be possibly with any sort of lookup via GlideRecord or similiar check. But, with that goal in mind I could split up the above ACL into 2 ACLS:

1. By role

Roles: change_manager,u_change_admin

2. By condition

Condition: current.state == -5 && (gs.getUserID() == current.opened_by || gs.getUserID() == current.requested_by)

Is there any performance to be gained by using the native role checks? My thought is the simplier each ACL is the easy it is to test and maintain. Obviously, with access to a field spread out over multplie ACLs make it harder to grok at first glance, but then I realized the description to the ACL seems to auto-update with the roles on save. So when viewing in a list grouped by field it's easier to see. Also, doesn't this make it easier to debug?

Bonus question: Let's say you have a requirement such as:

• All fields on change should be read-only, except Start Date, End Date, Title, Test plan, implementation plan, and backout plan, when:
  • The ticket is not closed and:
    • The user opened the change
    • The user is a change_manager
    • The user is part of the group: CAB

At minimum, it seems I would need 7 ACLs (one deny all, then 6 more, one for each field implementing the same logic. If this is scripted, it can be put in a Script Include to reduce duplicate code. Using the strategy outlined above it would require 19 (1 + 6 * 3) ACLs, so the scaliability of the above strategy might outweigh the benefits, if any.

Let me know your thoughts, thanks.

[shruti_tyagi]

Hi Richard,

1. Splitting your ACLs into two and adding conditions and roles instead of using advanced scripting in my opinion will improve performance. If we have record level acls, when we open list these acls run one by one to each each record in a list. So its good we are not checking script part every time. I think adding role and condition will help.

2. You Bonus Answer

I think you can achieve this by UI Policies, I would implement UI policy to make these fields read only using conditions instead of ACLs

Thanks

Shruti

If the reply was informational, please like, mark as helpful or mark as correct!

[Richard101]

1. Do you have any documentation that this will improve performance?

2. This was just an example, but UI Policies won't always work. For example: when you want to enforce row-levels or any access through web services or if you need a server script and don't want to use a AJAX call