Powerful customisations with Sugar’s ACL

Today I want to explore a customisation possibility that is so powerful and still often neglected: customising Sugar’s ACL framework.

The Actions and field visibility part of the ACL in Sugar is normally applied through the use of Roles within the application’s UI, while the visibility of a record is applied through the visibility framework that either allows a user to see a module’s entry or not.

There are two important nuances about Roles in Sugar that I should mention:

1. Most restrictive prevails, if a user happens to be assigned to more than one Role
2. Roles do not apply to Sugar Admin type users

The power of the ACL framework is due to the fact that it applies both to the back-end of the system (eg: the API will not allow writes) and to the UI as well by driving buttons and visual screen elements that would allow the user to perform or not the actions.

I do have two use-cases that often come up on Enterprise implementations, about making a module/record read-only.

 

Default a module to Read only, through ACL’s customisation

The first use case is about being able to keep a module read-only for all non-admin users, without the need of provisioning a Role to do so.

This normally applies to modules used only by an integration user for writing purposes, where an admin user or specifically selected one has the possibility of changing the data. I find this really useful for demo-purposes as well, as it can easily apply to multiple modules of this nature with minimal effort.

 

Conditional record locking through ACL’s customisation

The second (and slightly more complex) use case is around conditional record locking for all non-admin users, when certain conditions are met. A record becomes final after an irreversible action (eg: an approval process is completed, a sale has been finalised etc).

 

 

This framework gives you immense flexibility on the type of customisations that can be performed within the system. You can as an example, extend the above code prototypes to customise the system based on a user’s department, what type of records are read-only. This exact scenario is something that I’ve completed a while back on version 6.5.x of the product, and it is now pretty easy to do using the product’s flexible framework.

What you have to be aware of and careful about, is to make sure you do consider that the ACL is called everywhere, every time an action happens. My recommendation is to optimise as much as possible your code, profile it and load test it, to make sure your customisation is optimised and will perform well at scale.

I hope the above examples will help your next Sugar’s implementation.