Multisite, domain access and ACLs; howto get them to work together

[jcasharpe]

So I have two domains:  a.example.com and b.example.com. A has DOMAIN_ID 1 and B has id 2.

I am using domain access in Drupal to limit admin accounts to only be able to create content on their own sites. I then assign this user to a group used for ACL in CiviCRM; A admins and B admins. I then setup acl rules to limit their access to certain groups; e.g. A Users and B users.

If an admin from site B logs into site A then the ACLs are applied and she can see the groups and send mailings. If she logs into site B then the ACLs don't seem to be applied. Am I missing something about how to config ACLs to be applied to domain 2?

[Eileen]

It sounds like you are missing the multisite permissioning extension.

We are now using this version

https://github.com/eileenmcnaughton/org.civicrm.multisite

Which is not yet published as the new version but gets around some of the group nesting performance overhead of the published one.

[jcasharpe]

Will this work for 4.1? We're not quite ready to upgrade to 4.2/4.3 yet.

[Eileen]

I wouldn't go down the track of adding permissioning without upgrading to at least 4.2.10 (that's not out yet - but you could get a pretty good approximation by git clone git://github.com/fuzionnz/civicrm.git). There are some nasty performance gotchas prior to that.

However, it looks like you can still get the old module here

http://svn.civicrm.org/tools/branches/v4.1/drupal/modules/multisite/

You might need to edit the drupal version in the .info file

[jcasharpe]

Hang on, the multisite extension seems to do something slightly different to what I'm trying to achieve. I simply want standard ACLs to be applied on all domains that have a domain id that isnt 1. It seems they aren't being evaluated at all or something is restricting them; I've not yet gone down the route of debugging what ACL queries are happening.

[Eileen]

OK - I don't think there is a current way to do that. ie. standard ACLs apply to all domains

[jcasharpe]

Do you know what part of the code it is that limits it to domain_id 1? I've skimmed over the ACL/BAO/ACL.php code and I can't see anything. The only suspect thing is an access to $t['Domain'] when the array t doesn't have a Domain element; but there's nothing there that is dependant upon multisite being enabled.

[Eileen]

The multisite ACLs are outside the code base. They use the ACL hook.

You could try prefixing your drupal user_role or permissions table (using domain_prefix module) to give different permissions on different domains

[jcasharpe]

I'm trying to simply understand why my ACL gets applied if the same user logs into site A but on site B the ACLs aren't applied. A and B are the same drupal site (but use domain access to limit drupal content) and have civi multisite enabled (A has domain id 1 and B, 2).
i.e. I'm looking for the line of code that says if multisite is enabled then don't evaluate the ACLs!

[jcasharpe]

Found the problem! The civicrm_uf_match table includes domain_id; my drupal user was mapping to two different civicrm contacts, the second of which wasn't in the admin group and hence wasn't being given the correct permissions.

[Donald Lobo]

in d6 and previous differnt sites could share the user table

and hence the same contact id. however i think sharing tables has been obsoleted in d7 and cant use that trick anymore

lobo

[Eileen]

In James' case he is using domain_access so the user table is shared as a matter of course.

However, CiviCRM doesn't really understand this - you probably need a hook like this running to keep your uf match from getting in a mess - it just makes sure that when the uf_name for one domain is updated it is updated for others as well




/**
* * Implementation of hook_civicrm_post
*
* Current implemtation assumes shared user table for all sites -
* a more sophisticated version will be able to cope with a combination of shared user tables
* and separate user tables
*
* @param string $op
* @param string $objectName
* @param integer $objectId
* @param object $objectRef
*/
function multisite_civicrm_post($op, $objectName, $objectId, &$objectRef) {
  if ($op == 'edit' && $objectName == 'UFMatch') {
    static $updating = FALSE;
    if ($updating) {
      return; // prevent recursion
    }
    $updating = TRUE;
    $ufs = civicrm_api('uf_match', 'get', array(
      'version' => 3,
      'contact_id' => $objectRef->contact_id,
      'uf_id' => $objectRef->uf_id,
      'id' => array(
        '!=' => $objectRef->id
      )
    ));
    foreach ($ufs['values'] as $ufMatch) {
      civicrm_api('UFMatch', 'create', array(
        'version' => 3,
        'id' => $ufMatch['id'],
        'uf_name' => $objectRef->uf_name
      ));
    }
  }
}

[jcasharpe]

I don't understand why this hook is needed? I've created separate civicrm.settings.php files for each domain (but they point at the same drupal and civi dbs) where the domain id is set differently. The uf_match table already has a domain_id field so it should only update for the current domain, unless I'm missing something here? Is this something thats changed between 4.1 and 4.2/4.3?

[Eileen]

You have all your domains sharing one user table - but Civi doesn't understand that. So, if someone logs on & changes their drupal email address the uf_name field in the uf_match table will be updated - but ONLY for that domain (let's say domain #1). If that is a generic type address e.g. admin@org.com then that email might now belong to someone else - but if they try to create a contribution on domain #2 you will get an FK error as it tries to add a domain 2 entry for that email but it already exists.

The hook keeps the uf_match entries in sync

[jcasharpe]

Ah right; I get it.
I guess that only works if you have completely shared user tables because it works on the assumption that the changed uf_name corresponds to the same CMS id which is valid in this case but not in the general case. I guess this should all be documented somewhere as it requires knowledge of the internal workings to realise whats going on...