Alice in multi-org land - successes and problems

[petednz]

So reporting back - we are setting up a multi-org sandbox to find where the gotchas may be.

Following instructions http://wiki.civicrm.org/confluence/display/CRMDOC/Multi-Org+Installation+Example we got to
TODO: Fill in the steps for setting up the ACLs, roles, etc.

and filled in the blanks, setting up an ACL managers group for each 'org' and giving them ACL role over the relevant org.

Then turned off Permissions to 'view/edit all contacts' and hey presto individuals created by mgr of Org A do not get seen by mgr of Org B and v.v. - yay - well done everyone.

So then some experimenting.

IMPORTS and GROUPS - when Mgr B imports all the contacts get added to Org B and are therefore not visible to Mgr A. Excellent

But when I import I added them to a new group - and then when I clicked on the Group to see they had been added I got Access Denied.

So I tested by creating a Group via 'manage groups' and while I could add it, as soon as i get to the window to 'add contacts' the group is not accessible.

Is this some conflict in permissions that i need 'view all contacts' to be able to see Groups? Have I taken the wrong pill or fallen down the wrong hole?

Also might multi-orgs deserve a child board so we can cluster these issues in one place?

[Donald Lobo]

that is a bug in the multi-site code

can you please file an issue. Deepak is on vacation for the next couple of weeks, so he'll look at it when he gets back. We'll incorporate the fix into 3.1 at that stage

lob

[petednz]

Hi Lobo - well it is always somewhat reassuring to know I am not just trying to open the door by pushing when I should be pulling.

Ticket is here http://issues.civicrm.org/jira/browse/CRM-5417

We are going to have to do some heavy testing in this area so will try and confer with the others who are doing same.

[davej]

Just spotted that http://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation - which is more complete and current than the link you posted - doesn't mention the multisite integration module for drupal. Also spotted that this module isn't part of the Civi 3.0.2 tarball. I'd been using a version from svn. I believe this is the correct location: http://svn.civicrm.org/tools/trunk/drupal/modules/multisite/

The multisite module does the ACL magic for you: if you're logged into site N (and don't have permission to view or edit all contacts, or administer multi org) then it automatically grants you access to site N's parent group & subgroups thereof*. You needn't & shouldn't manually set up ACL for this.

* If the site parent group has no child groups, this doesn't work - CRM-5418.

Dave J

[petednz]

Excellent - thought i was missing some key - guess i will try reversing the ACLs i set up and see where it gets me.

Many thanks for the pointer.

We had been using those instructions but it seemed that Wes' other bit continued the story - and indicates it does as such.

Maybe my eyes are glazing over but not sure the drupal module you refer to is referenced in either of the wiki pages.

Will do some digging.

cheers

[petednz]

Okay - so round two - knowing about the missing module helped 

Seem to have ACL stuff working for contacts so trying out some other things.

GROUPS (I will use state-group to indicate a group that is being set up for use by a state - and State-Group to indicate THE group that IS the state - if you get my drift)

if I want a group that operates trans-states ie imagine that each state has a bunch of treasurers, and at national level I set up a Group of Treasurers, and have all Treasurers from all states and sub-states in it.

Seemed to me that the Group would only show under Manage Groups or Adv Search at the state level if I set that group to have all the State-Groups as its parents as well as the National Group - which makes sense logically.

But doing that meant that when a state-manager accessed members in the Group they could see and access contacts from the other states  - which should be a no-no. And when i removed an example contact from this group, sure enough they were no longer visible to the state-managers that the contact was not a part of.

hope that makes sense but it suggests something is borked. But would be great if someone else with multi-org install could confirm that this is NOT the case for them, then I would know to keep digging on our install rather than looking at problems in the code.

Second issue with Groups, is that before the patch, i set up a state-group that had the State-Group as the Parent group - and surprisingly i could see it from other States.

also when i am logged in via a State and create a group, if there are no other groups already in the state then I see no 'parent orgs' - and it refuses to let me save (no error msg)

If i am in a state that already has a group it tells me that 'add parent' is a required field, but since it does not show me the State-Group then I don't know what I am meant to make the Parent.

And if i set up a group for StateA while logged in at National so I can use StateA-Group as the Parent group, when i am logged in at StateA, I can see the group, I can add contcts to the Group, but when I click on the group I get an Access Denied msg

I suspect some coding has been done to 'hide' the child-orgs own group eg so it does show up on every child-org-contacts Group lists - but i wonder if it does need to show in the list of Groups at least so i can make it the Parent of all the groups i need for the child-org.

the above would be easier to explain with little boxes but ....

Would it be a massive ask to have a multi-org set as a sandbox by the civi team - something we can test again to check odd behaviour isn't some of our own doing?

Otherwise, chris has made some progress using acl hook so we can have Custom Data Tabs easily set up so they can be made visible only at the relevant state-site - see post here http://forum.civicrm.org/index.php/topic,10949.0.html.

[petednz]

I suppose another way of dealing with the above is see if someone can confirm the logic

Scenario National and States

1/ If a Group needs to be seen by users of any and all States and at the National level (ie StateA can see its conacts in that group, StateB can see its contacts, and National can see them all, then should it have all of the State-Groups and the National-Group as its Parents?

2/ If a Group (calling it a subgroup) is set up for a State's internal needs,

a/ does it need to have the State-Group as its Parent (currently not possible since the State-Group is not visible in the list of possible Parent Groups)

b/ should that state-subgroup only  be visible within it's State parent (and National) and not to other States? (currently it is showing to all States)

[davej]

Hi Peter,

I think what you're trying to do goes beyond what has been implemented for multi-org. The terminology we've been using is L1 for top-level site (your National), L2 for 2nd-level (your States). Sounds like you want to define a group, e.g. Treasurers, in L1 and have it so that from L2 site A, you just see the intersection of Treasurers with site A's parent group. This would be good but the Civi team's decision was that it would be too difficult to implement.

One approach is to use tags for categorisation that applies across all L2 sites and groups for categorisation within L2 sites.

Re: creating groups, if you create a group on L2 site A then it should automatically get site A's parent group as its parent. If not, this suggests a problem with your setup. Have you verified that you have the correct domain ids, group ids and contact ids, respectively, specified for CIVICRM_DOMAIN_ID, CIVICRM_DOMAIN_GROUP_ID and CIVICRM_DOMAIN_ORG_ID in each site's civicrm.settings.php? See CRM_Core_BAO_Domain::getGroupId.

Regards,

Dave J

[petednz]

HI Dave

Well we are having no joy still.

Instructions  seem hard to follow so we may have left the road at some point.

We have the patched multisite module installed, though on Round3 it wasn't enabled till after some set up had been done but since the xxxxxxxxx it doesn't seem like that could affect it?

The IDs we have are as follows

Dom ID // Dom Gp ID // Dom Org ID

L1 = 1, Null, Null - and the related Group ID is 2
L2a = 2, 2, 3    - the related Group ID for this is 3 as is the Associated Org ID - does this look right?
L2b = 3, 2, 4    - the related Group ID for this is 4 as is the Associated Org ID etc
L2c = 4, 2, 5    - etc

NB Group ID 2 belongs to the 'default domain name' group. Also this Group has NOT been associated with its Organisation - should it? I have tried it with it Associated to the L1 Org but nothing seems to have changed

Currently someone who does not have 'view/edit all contacts' or 'administer multisite" at the L2 level is seeing all contacts and all groups. So I don't get what is tagging the person as 'belonging' to the L2 Group

When a contact is added at L2 they show (at L1) as belonging to GID=2 (Default Domain) and that is all.

So some (more) questions

Does an L2 manager need to have been added to the L2 Group? Have tried it both ways and seems to have no effect.

It would really help if I understood a bit more about what the intentions are of this so i know when we are hitting and missing the target. thanks

[davej]

Hi Peter,

Your CIVICRM_DOMAIN_GROUP_IDs are wrong. Each site L1, L2a, L2b, ... should have its own master Organization and Group (the Site Org & Site Group):

Site L1: Site Org1, Site Group1
Site L2a: Site Org2a, Site Group2a
Site L2b: Site Org2b, Site Group2b
...

Each site's civicrm.settings.php should have CIVICRM_DOMAIN_GROUP_ID set to the id of that site's Site Group, and CIVICRM_DOMAIN_ORG_ID set to the id of that site's Site Org.

Each Site Group should be associated with its Site Org.

If it's working correctly, as I said a new contact created on site N should automatically become a member of Site Group N.

We have Org2a, Org 2b, ... as children of Org1, which means that a user on site1 without view all contacts perm can see the contacts of L1 and all L2 sites - but in this simple hierarchy, this can be achieved with view all contacts perm anyway. Whether this is relevant depends on what sort of hierarchy you have.

Hope this helps,

Dave

[Dave Greenberg]

Dave / Peter - I'm "hoping" that some relatively complete and accurate docs about "what multi-site / multi-org" does (and doesn't do) and how to install and use it can come out of this discussion. I'm feeling a bit clueless and confused (not even sure if multi-site and multi-org are 2 different things :-( ).

It seems like the actual implementation was driven by an "unlinked" set of Jira issues - and I haven't found a "spec" that pulls things together (altho it may be out there). There are also some docs on the wiki that I think are obsolete or on a different theoretical tangent - but not sure. EX: http://wiki.civicrm.org/confluence/display/CRM/Multi-Organization+Support+in+CiviCRM

If the multi-org example is incomplete then it probably should be merged it with the "more current" page. Also, I didn't see any reference to "installing a separate multisite module for Drupal"  in the Multi-site Installation doc  (did i miss it)

I think having an overview and how-to that's current will help adoption and solidification of this feature set. Any takers ?

[Chris Burgess]

Your CIVICRM_DOMAIN_GROUP_IDs are wrong. Each site L1, L2a, L2b, ... should have its own master Organization and Group (the Site Org & Site Group):

Site L1: Site Org1, Site Group1
Site L2a: Site Org2a, Site Group2a
Site L2b: Site Org2b, Site Group2b
...

Each site's civicrm.settings.php should have CIVICRM_DOMAIN_GROUP_ID set to the id of that site's Site Group, and CIVICRM_DOMAIN_ORG_ID set to the id of that site's Site Org.

Each Site Group should be associated with its Site Org.

Pete and I both read the multi-site install docs as suggesting that the sub-sites should define the parent site's Group as CIVICRM_DOMAIN_GROUP_ID (though I only decided this was correct on my third reading of the page). There it says,

8. Register domain/site group

In multi-org installation, it is required to have a top-level org/group to represent the multi-org hierarchy root. When you login to the site and go to "manage groups" screen, you will notice a group with the name as that of domain. System requires you to register this master group responsible for holding sub-groups/contacts.

You can either edit this group or create your own group and register that. To register modify civicrm.settings.php file (for site2) to change following line -

define( 'CIVICRM_DOMAIN_GROUP_ID', null );
To
define( 'CIVICRM_DOMAIN_GROUP_ID', 2 );

Assuming master group id is 2

Because the default group settings are 1=Administrators and then 2=top-level org when following these docs, and the group references in this doc are to "a top-level org/group to represent the multi-org hierarchy root", these indicated that in the sub-sites we should have define('CIVICRM_DOMAIN_GROUP_ID', 2); to attach the sub-sites to the master group. But you say that this isn't the case?

[Chris Burgess]

So to clarify - here's the Domain, Group and Org IDs -

Code: [Select]

SELECT d.name, d.id AS domain_id, g.id AS group_id, o.id AS org_id
  FROM civicrm_domain d
  JOIN civicrm_group g ON g.title LIKE CONCAT('MyOrg ',d.name)
  JOIN civicrm_contact o ON o.display_name LIKE CONCAT('MyOrg ',d.name);
+------+-----------+----------+--------+
| name | domain_id | group_id | org_id |
+------+-----------+----------+--------+
| ACT  |         2 |        3 |      3 |
| NSW  |         3 |        4 |      4 |
| NT   |         4 |        5 |      5 |
| SA   |         6 |        6 |      6 |
| TAS  |         7 |        7 |      7 |
| VIC  |         8 |        8 |      8 |
| WA   |         9 |        9 |      9 |
| QLD  |         5 |       10 |     10 |
+------+-----------+----------+--------+
8 rows in set (0.00 sec)

So the correct settings here are for the parent site (L1) to have:

Code: [Select]

define( 'CIVICRM_MULTISITE'      , 1 );
define( 'CIVICRM_DOMAIN_ID'      , 1 );
define( 'CIVICRM_DOMAIN_GROUP_ID', null );
define( 'CIVICRM_DOMAIN_ORG_ID'  , null );

And the sub-site for QLD to have:

Code: [Select]

define( 'CIVICRM_MULTISITE'      , 1 );
define( 'CIVICRM_DOMAIN_ID'      , 5 );
define( 'CIVICRM_DOMAIN_GROUP_ID', 10 );
define( 'CIVICRM_DOMAIN_ORG_ID'  , 10 );

Does that look right?

[petednz]

Thanks for keeping us going here DaveJ
So with the above config we add a new individual at L2a
That individual is auto-joined to L2a ParentGroup

So far so good it seems.

Re: creating groups, if you create a group on L2 site A then it should automatically get site A's parent group as its parent. If not, this suggests a problem with your setup.

If I create a Group in L2a then it requires a Parent Group but does not give me any options. If i first make a L2 Group at the National level and set it with the L2MainGroup as its parent, then that group becomes visible in the 'Add Parent' option back at 'new group' at L2.

So I guess that means something is still not lining up. Maybe time to trash and begin round5

[davej]

Dave / Peter - I'm "hoping" that some relatively complete and accurate docs about "what multi-site / multi-org" does (and doesn't do) and how to install and use it can come out of this discussion. I'm feeling a bit clueless and confused (not even sure if multi-site and multi-org are 2 different things :-( ).

It seems like the actual implementation was driven by an "unlinked" set of Jira issues - and I haven't found a "spec" that pulls things together (altho it may be out there). There are also some docs on the wiki that I think are obsolete or on a different theoretical tangent - but not sure. EX: http://wiki.civicrm.org/confluence/display/CRM/Multi-Organization+Support+in+CiviCRM

The current implementation was sponsored by PIRG (via Wes Morgan) and Greater Manchester/Greater Merseyside voluntary sector support organisations (via Circle Interactive - my colleague David Moreton). Wes documented some use cases on the wiki: http://wiki.civicrm.org/confluence/display/CRM/Multi-Org+Use+Cases and I think this formed the starting point for a spec that was then refined with Lobo via email.

I think "multi-org" and "multi-site" are being used interchangeably.

If the multi-org example is incomplete then it probably should be merged it with the "more current" page. Also, I didn't see any reference to "installing a separate multisite module for Drupal"  in the Multi-site Installation doc  (did i miss it)

I've added a paragraph about the multisite module at http://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation .

I think having an overview and how-to that's current will help adoption and solidification of this feature set. Any takers ?

I'm happy to be a contributor to this when I have time but I'm being pulled away onto other urgent projects at the moment.

So the correct settings here are for the parent site (L1) to have:

Code: [Select]

define( 'CIVICRM_MULTISITE'      , 1 );
define( 'CIVICRM_DOMAIN_ID'      , 1 );
define( 'CIVICRM_DOMAIN_GROUP_ID', null );
define( 'CIVICRM_DOMAIN_ORG_ID'  , null );


We have a Site Group & Org defined for L1 too.

And the sub-site for QLD to have:

Code: [Select]

define( 'CIVICRM_MULTISITE'      , 1 );
define( 'CIVICRM_DOMAIN_ID'      , 5 );
define( 'CIVICRM_DOMAIN_GROUP_ID', 10 );
define( 'CIVICRM_DOMAIN_ORG_ID'  , 10 );

Does that look right?

Yes, I reckon.

Re: creating groups, if you create a group on L2 site A then it should automatically get site A's parent group as its parent. If not, this suggests a problem with your setup.

If I create a Group in L2a then it requires a Parent Group but does not give me any options. If i first make a L2 Group at the National level and set it with the L2MainGroup as its parent, then that group becomes visible in the 'Add Parent' option back at 'new group' at L2.

So I guess that means something is still not lining up. Maybe time to trash and begin round5

Ah, I've just seen the same issue on our setup. This used to work. A change was made to multisite.module to hide the site parent group: http://forum.civicrm.org/index.php?topic=9310.0 but it's evidently being hidden in a case where it's needed, or at least the add group form validation & processing code needs to know when to implicitly use the site group as parent.

As a workaround, in multisite.module change false to true at line 106:

Code: [Select]

$currentGroups = _multisite_get_all_child_groups( $groupID, false );
I'll put something on JIRA.

Dave J