We are a federated political organisation migrating to CiviCRM 4.6. I have integrated CiviCRM with Drupal views and civicrm_entity so we can create customised search pages for local organisers.

I'm finding civicrm_entity and various fuzion extensions to be excellent help, but setting up permissions across a large grassroots organisation is still complex. We are currently managing this with a combo of permissioned relationships and auto-generated smart groups.


Currently, to view entity via civicrm_entity (at e.g. civicrm-contact/[id]), a user seems to require the 'view all contacts' Drupal permission.

Is there an easy(ish) way to make civicrm_entity respect CiviCRM ACLs? Or at least check that the logged in user has permissioned relationship with that contact?

thanks, L

  • Update: in the meantime we are using permissioned relationships to allow access to a special view at members/%. So when a user visits_members/1234_ their relationship to the member via different Organisations (branches, committees, etc.) is checked and the view is only shown if the relationships are permissioned all the way down. This is working quite well so far.
    – Leckie
    Nov 21, 2016 at 15:37
  • 1
    This is how we have done a lot of this type of thing - using those Fuzion modules and daisy-chaining relationships between the member, their branch, the region of that branch, and all the way up, with officers who are 'related' to the branch or region therefore getting access down the tree.
    – petednz - fuzion
    Jan 14, 2017 at 3:38

1 Answer 1


I wish i would have seen this question earlier, I can certainly help you out.

checkout civicrm_entity.api.php in the civicrm_entity module

I don't believe the controller is checking the ACL's when loading an entity. We may be able to add 'check_permissions' => True to the call there in civcirm_entity_controller.inc CivicrmEntityController::loadEntites... food for thought, make a feature request in the civicrm_entity queue if you still need this.


There is a hook, hook_civicrm_entity_supported_info() that you can implement and add entities to be exposed by the module or alter settings for the currently exposed entities. See the api information for full details.

Here you can alter what permissions are necessary to view/add/edit/delete entities via the CiviCRM Entity Drupal based forms or even set a custom callback.

function MYMODULE_civicrm_entity_supported_info(&$civicrm_entity_info) {
      $civicrm_entity_info['civicrm_contact'] = array(
        'permissions' => array(
          'access_callback' => 'MYMODULE_some_custom_callback_name'

This will tell CiviCRM Entity to use your custom callback instead of 'user_access'

Your callback will look something like this:

    function MYMODULE_some_custom_callback_name($op, $entity_type, $entity, $account) {
      if (is_null($account)) {
        global $user;
        $account = $user;
       if($entity_type == 'civicrm_contact' && $op == 'view') {
         // fetch contact_id for user via a uf_match api get call
         // do your custom permission check
         $rules = getAllByContact($contact_id); //maybe get the acl rules for a contact
        // determine whether the contact can view with some code here
        // then assuming the contact can view the contact
        $contact_can_view = TRUE;
        // or if not
        $contact_can_view = FALSE;
         return $contact_can_view; 

see some useful information about getting ACL rules for a contact here: https://wiki.civicrm.org/confluence/display/CRM/Access+Control+List+Permissioning+Specification

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.