- Issue created by @markusa
A request has been made to make Drupal Views of CiviCRM Entity types respect CiviCRM ACLs.
Default behavior for 10+ years has been that Views does not respect ACLs. This was true in the Core maintained Drupal 6/7 integration, and is true in the CiviCRM D8/9/10 versions.
CiviCRM ACLs https://docs.civicrm.org/user/en/latest/initial-set-up/permissions-and-a...
This Core CiviCRM functionality provides ability to grant or limit what contacts's and associated data can be viewed or edited by other contacts.
Extensions can extend the Core functionality, such as the Activity Type ACL https://civicrm.org/extensions/activity-type-acl
Developers can extend Core functionality via hooks https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_selectWhereCla...
https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_aclWhereClause/
ACLs are implemented in CiviCRM by applying additional query where conditions in a variety of the contexts, such as Search pages, Reports, or Contact Summary page
By default CiviCRM Entity allows site builders to create Views listing CiviCRM data. There is no access control built into the module for Views rows.
There is access control for viewing CiviCRM entities in "renderings". An example is to configure the View to format the rows as renderings of display mode, "Full Content" or "Teaser". When this is used, then users must have permissions to view them.
Default permissions are set in this file: https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Suppor...
To view renderings of Contacts, for example, a user needs "view all contacts" permission.
Developers can alter the default permissions for the entity operations in a hook. hook_civicrm_alter_drupal_entities(&$civicrm_entity_info)
Developers can also implement standard Drupal access control hooks to meet custom needs, for example, hook_entity_access() https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
Developers can also choose to override the default CiviCRM Entity access control object and enforce Views row permissions. Which was taken out of the module by request, to have D7 equivalence:
The MR taking it out: https://github.com/eileenmcnaughton/civicrm_entity/commit/032fc7d32c78b9...
Views is commonly used to make custom reports, although there are many other uses. User / member dashboards are often constructed. Views is used to generate blocks that can be placed on any page.
Developers create unique functionality, sometimes using Views, for a myriad of bespoke reasons.
1000s of sites use CiviCRM Entity, and for years ACLs have not been respected.
Should we choose to implement respecting ACLs, all sites owners using CiviCRM Entity would need to review their Views and their use cases, and decide if they do or don't need them to respect ACLs.
There is a setting in each View, "Disable SQL Rewriting". If we do implement this new feature, we would plan on implementing it in such as way, as site builders could choose to set this setting, and the query re-writing that would apply ACLs could be ignored.
A site that does not use ACLs at all would not be effected.
Drupal is an apple, and CiviCRM is an orange, they're both fruits, but still different.
Drupal's access control for nodes involves a concept of "grants" and does do query alterations. This is the closest equivalent to CiviCRM ACLs.
Access control for other entity types are not determined generally by grants for nodes.
Generally any entity type determines access for a particular entity based on user role permissions. Custom implementations calculate based on a particular entity id.
Access control determinations, and query alterations are cached in Drupal. The first time you load an entity, the access is determined for a user, but the next time it is loaded the cached result is used, and it is not recalculated.
Events for changes to the criteria for a contact's ACL roles, ACL role assignments, etc.. are not broadcast in such a way that the Drupal system can be made aware, invalidate caches, and then recalculate access on subsequent page loads.
One or more Drupal cache contexts will need to be developed, and code added to detect relevant changes. For example, ACL role maybe assigned for all contacts in a CiviCRM Group "Admins". We would need to invalidate cache for a contact, if that contact is added that Group.
Caches for other entity types, like activities, contributions, etc. .may also need to be invalidated at the same time as a contact.
Additionally this may require CiviCRM core updates to broadcast that ACL Role and role assignments were updated.
This is very likely going to take more time to develop than the actual query alterations when a View is executed.
Should respecting ACLs be enabled by default on module install, or should site admins be required to enable it in CiviCRM Entity settings.
Similarly, for people already using CiviCRM Entity, and upgrading to a version including this feature, should ACLs be turned on automatically and force site builders to review and update Views settings as necessary?
What all entity types could or should potentially respect CiviCRM ACLs?
By default should a user see NO Views rows, unless they are granted permission via ACL?
CiviCRM itself mixes user permissions and ACLs. Do we duplicate the mix of user permissions and ACLs that Civi uses for search, contact summary or the other contexts?
Should ACLs be respected for "renderings"? e.g Non-views pages like /civicrm-contact/[id] or entities that are referenced by Entity Reference fields from nodes? I feel like NO on that, as once you are rendering an entity, Drupal rules should apply.
What do site owners who use CiviCRM Entity think?
Is this a feature that is desired or not?
Are any organizations willing to invest in its development?
Active
4.0
Code