CiviCRM ACL's (Access Control List) explained ..

Good background reading for ACL's can be found in the Wikipedia entry Permissioning is quite important in CRM systems. CiviCRM used Drupal's permissioning system and stretched it a fair amount till v1.6. It had two major disadvantages: One, our joomla users do not have access to the permissioning model. Two, the Drupal model did not scale very well from a user interface perspective. This was primarily because it displayed all the permissions as a grid. If you had 300 roles and 300 smart groups, drupal displayed a table with 90,000 checkboxes. The browser would definitely not be happy with this chunk of HTML In v1.6 we moved permissioning for civicrm groups to a more generic ACL model. You can read detailed implementation notes about this feature on our wiki. The new model is more efficient in terms of being able to scale to a large number of groups and contacts. It also lays the foundation for us to layer a more powerful system that users can customize and extend easily. In v1.7 permissioning for custom groups and profiles has been implemented. The CiviCRM admin can decide which group of users can interact with a custom group or profile. Financial / Donation data on your constituent can be hidden from everyone but finance and executive staff while volunteer data can be viewed by all staff members. You can also permission profiles and expose different profiles to different folks. Anonymous users will be prohibited from accessing a member specific profile. Similar to Drupal, permissions are based on three objects:

Role

An ACL Role is attached to a static CiviCRM group. You always grant (or deny) a permission to a role. There are three special roles:

• Any Role: All users are part of this role.
• Authenticated Role: Authenticated users get this role
• Administrator Role: The CiviCRM admin needs to attach this role to a set of contacts who are the site admins.

Thus a user can have one or more Roles in the system

Operation

There are different Operations that can be performed on a object. Different types of operations are Edit, View, Create, Delete and Search. Currently we have only implemented the Edit and View operation. Over a period of time, we will add support for more operations

Target Data

This represents the object that is being permissioned. Currently CiviCRM supports ACL's on Groups (static and smart), Custom Groups and Profiles. I suspect we will switch to ACL's as the only permissioning mechanism in v1.8 or v1.9

Examples

• Administrator can perform any operation on any data. This should be the default in a future version.
• Anonymous users can view/edit Profile A
• Staff can view/edit all contacts
• Staff can view/edit custom groups A, B, C
• Finance and Executive can view/edit custom group 'Financial Information'

Limitations of the current model

• ACL's do not work in Joomla (a recent discovery!). To make the transition from drupal permissioning easier and to hide the complexity of ACLs from most of the user base, we use drupal permissions to trigger the use of ACL's. Since joomla permissions do no exist, the above triggering does not happen
• All operations have not been implemented on the Target Data
• Deny operator is not supported. i.e. staff have access to ALL custom groups DENY Finance Custom Group
• Tokenized Smart Groups. i.e. Rather than having to create 50 smart groups, one for each state, you create one "state" tokenized smart group. This will reduce the number of groups significantly

As in all things in CiviCRM land, we will address the above shortcomings in future releases. Our release early, release often philosophy has been working quite nicely and we hope to continue to integrate some of the above in future releases