Author Topic: Alice in multi-org land - successes and problems (Read 11871 times)

petednz · November 24, 2009, 10:30:18 am

Davej - thanks for all your responses - it can be sooo painful chasing in circles (no pun intended) trying to catch a tail when actually there may not be a tail there.

I will amend as per your suggestions and see how we go.

Pete

davej · November 24, 2009, 10:58:46 am

Glad it's helpful. Things were working quite well with our initial multi-site installation from svn but I'm wondering if there may have been a regression in 3.0.2 and/or code changes made since our initial setup (e.g. includeParent in multisite.module - which was at my request among others) may have exposed issues in scenarios that haven't been tested since. Lobo says they'll look into it when Deepak gets back next week - he did much of the multi-org implementation.

For reference, some relevant JIRA issues:

Multisite module: hide site parent group from users without administer Multiple Organizations permission
Multisite module: aclWhereClause allows no groups when site group has no children
Multi-org: Manage Groups lists all groups and requires administer CiviCRM permission

While I'm at it, this may be of interest too:

Add ACL Support for CiviReports, Autocomplete contact search widget, and Full-text search

Cheers,

Dave

petednz · November 24, 2009, 11:07:01 am

Hurry up Deepak ;-)

Will look through that other stuff. I really need to get a good steer on what multi-org can or might be able to do since this is going to be a fairly urgent decision as to whether we stick with just an ACL approach or not.

Donald Lobo · November 24, 2009, 11:23:16 am

deepak is off till dec 5th, so 10 more days

davej: u might want to avoid upgrading till he gets back

lobo

petednz · November 24, 2009, 11:28:30 am

ok so i made the changes davej said to the module (and added the GID and CID for L1) and now at L2 when I create a new group is see the L2ParentGroup listing automatically - thx

petednz · November 24, 2009, 11:33:45 am

Deepak deserves all the holidays he can get - just not now!

with the fix in place my observation is that if i have created a group at the level L2a at level L2b I can see that Group via Manage Groups (bad) but get an Access Denied if I click on Members (good)

My goal would be that the only groups listed on the Manage Groups at L2 level would be those pertaining to the particular L2 Org - would others agree?

Maybe I need to move over to a wiki and help bash together what our collective expectations are here.

davej · November 25, 2009, 02:24:33 am

Quote from: peterd on November 24, 2009, 11:33:45 am

with the fix in place my observation is that if i have created a group at the level L2a at level L2b I can see that Group via Manage Groups (bad) but get an Access Denied if I click on Members (good)

My goal would be that the only groups listed on the Manage Groups at L2 level would be those pertaining to the particular L2 Org - would others agree?

Agreed and that's how it worked in previous svn versions we tested - see Multi-org: Manage Groups lists all groups and requires administer CiviCRM permission. I think 3.0.2 has regressed, we had someone testing yesterday who found that segregation ("siloing") was failing in various contexts where it was working previously:

Manage Groups - Discussed above.

Events - Tester reported:

"Using L2a Big Event

Each CVS can see each other's events at participation registration

Partcipants leak at "register new participant"

Adding leaked participant gives error - "Event registration for has been added. You do not have the necessary permission to view this contact." Note even the contact name has been removed from the error message, but you could see it before saving.

In manage events you cannot see the leaked addition and it is not included in the list of participants. However both appear in L1 Event management screens

L2a's Big Event appears in L2b's event management screen when one of its participants has been included and gives L2b full configuration opportunities

In fact even with no participants from your area you can see and configure other areas' events it seems."

Memberships - Tester reported:

"Leakage of contacts and Membership Types at addition stage - can see other areas contacts and other areas membership types, can add contact to type but unable to view subsequently, other than quantity in dashboard

Can add contacts to other areas membership types, but no info on type subsequently

Other area contacts highlighted in Recent items though"

I'm hoping the regressions have a single cause.

Dave

petednz · November 25, 2009, 10:10:18 am

Hi Dave - sounds like i am trying things out during a particular unstable period - I will aim to add those comments to my musings wiki here http://wiki.civicrm.org/confluence/display/CRMDOC/Multi-org+and+multi-site+musing

davej · December 02, 2009, 05:24:05 am

Quote from: davej on November 25, 2009, 02:24:33 am

Events ...Partcipants leak...

Reported as http://issues.civicrm.org/jira/browse/CRM-5472

Quote from: davej on November 25, 2009, 02:24:33 am

Memberships ...Leakage of contacts...

Reported as http://issues.civicrm.org/jira/browse/CRM-5473

Dave J

davej · December 08, 2009, 09:34:40 am

Latest on IRC...

Dec 08 13:18:02 <deepaks> davej_: CRM-5418, CRM-4901, CRM-5473, CRM-5438 are all fixed. If you can have a quick look and see if they work as expected, would be great.

I've checked these and added comments. In brief:

CRM-5418 Multisite module: aclWhereClause allows no groups when site group has no children:
fixed.

CRM-4901 Multisite module: hide site parent group from users without administer Multiple Organizations permission:
fixed.

CRM-5473 Multi-org: ACL failure / leakage in CiviMember:
"Leakage of contacts" is already fixed in 3.1. "Leakage of Membership Types" has been fixed.

CRM-5438 Multi-org: Manage Groups lists all groups and requires administer CiviCRM permission:
fixed.

CRM-5472 Multi-org: ACL failure / leakage in CiviEvent:
Consists of three issues:
1. Other sites' Events are visible.
2. When registering participants, other sites' contacts are visible.
3. Having registered another site's participant for another site's event you get full control of the event.
#2 is fixed in 3.1 . #1, #3 are a case of "the dog ate my spec". Watch this space.

Good work, Deepak! Good to have you back. :-)

Dave J

petednz · December 08, 2009, 12:55:08 pm

Get rid of that dog ;-)

Has any thought been given to trying to include Activities within this approach. Just thinking about different organisations at L2 level wanting to have their 'own' types of Activities, and whether we can help keep the interfaces cleaner for the others so that L2a own Activities aren't visible for L2b.

Am also trying to think of other situations where having a dozen or so L2 orgs could result in some very long option lists.

Hopefully the Event stuff above can be worked through.

Good work both of you.

petednz · December 08, 2009, 03:36:57 pm

And a couple more for the pot

Relationships - I can see it being really useful if Relationships could be 'contained' at subsidiary levels - again because L2a may use different types to L2b - and any clutter we can avoid is good.

Multi-level - how many levels are you suggesting this system may work for? I wasn't thinking beyond 2 since not sure there is a case of having an L3 site but not sure I have seen anyone say 'no' - can we look at going to L3 or even L4 with this approach (and will it work if we don't actually have an L3 site - not sure I have yet got it clear where this approach exceeds what is available via ACL or ACL hook, or whether we just look to go to L2 and do the rest via ACL hooks. Any comments?

petednz · December 08, 2009, 11:43:18 pm

And one final one before I let someone else get a word in edgeways. Chris asked this question on another post but hasn't been responded to so thought I would flick it in here (from http://forum.civicrm.org/index.php/topic,10949.0.html)

Quote

I've done ACL restrictions based on the current logged-in user's contact ID, but I see that in the multisite module you're simply using the group ID to apply restrictions. Does this indicate that for PIRG, you are preventing users from one multisite install from even logging into another multisite install?

If so: what method are you using for sites running multisite.module? Separated users tables? Validation in hook_user()? Something else?

Without that, it seems like users from SiteB would be able to access contacts and custom data from SiteC simply by logging into SiteC using their SiteB creds.

davej · December 09, 2009, 02:38:41 am

Quote from: peterd on December 08, 2009, 12:55:08 pm

Has any thought been given to trying to include Activities within this approach. Just thinking about different organisations at L2 level wanting to have their 'own' types of Activities, and whether we can help keep the interfaces cleaner for the others so that L2a own Activities aren't visible for L2b.

Am also trying to think of other situations where having a dozen or so L2 orgs could result in some very long option lists.

Part of the rationale of GM2, who co-funded the multi-org work with PIRG, was to impose uniformity of data collection across a set of organisations, to allow meaningful reporting and comparisons across sites. So they wanted most things to be configured globally, including activity types. A spreadsheet has been unearthed detailing what was agreed to be global versus local (per-site), attached.

I think the decision of what should be global versus local will inevitably differ from project to project. I'm sure the Civi team would be happy to implement further per-site features if someone wanted to sponsor it.

Quote from: peterd on December 08, 2009, 12:55:08 pm

Hopefully the Event stuff above can be worked through.

Currently in discussion and scheduled for 3.1 or 3.1.1 .

Quote from: peterd on December 08, 2009, 03:36:57 pm

Multi-level - how many levels are you suggesting this system may work for? I wasn't thinking beyond 2 since not sure there is a case of having an L3 site but not sure I have seen anyone say 'no' - can we look at going to L3 or even L4 with this approach (and will it work if we don't actually have an L3 site - not sure I have yet got it clear where this approach exceeds what is available via ACL or ACL hook, or whether we just look to go to L2 and do the rest via ACL hooks. Any comments?

I believe it's not limited to a set number of levels. The only distinction between our L1 and L2 sites is that the L2 parent groups are children of the L1 parent group. So you could add an L3 whose parent group is a child of an L2 parent group. Or an L0 whose parent group is the parent of an L1 parent group.

Quote from: peterd on December 08, 2009, 11:43:18 pm

And one final one before I let someone else get a word in edgeways. Chris asked this question on another post but hasn't been responded to so thought I would flick it in here (from http://forum.civicrm.org/index.php/topic,10949.0.html)
Quote
I've done ACL restrictions based on the current logged-in user's contact ID, but I see that in the multisite module you're simply using the group ID to apply restrictions. Does this indicate that for PIRG, you are preventing users from one multisite install from even logging into another multisite install?

If so: what method are you using for sites running multisite.module? Separated users tables? Validation in hook_user()? Something else?

Without that, it seems like users from SiteB would be able to access contacts and custom data from SiteC simply by logging into SiteC using their SiteB creds.

There's 1 Civi db and N Drupal dbs, therefore N user tables. civicrm_uf_match now has a domain_id.

There's a constant you can set in civicrm.settings.php: CIVICRM_UNIQ_EMAIL_PER_SITE, which controls whether users with the same email address in the user tables of Drupal dbs L2a and L2b map to the same Civi contact or different Civi contacts. See CRM_Contact_BAO_Contact::matchContactOnEmail().

Dave J

petednz · December 09, 2009, 11:52:24 am

Marvellous. Thanks for the response

CiviCRM Community Forums (archive)

News:

Author Topic: Alice in multi-org land - successes and problems (Read 11871 times)

petednz

Re: Alice in multi-org land - successes and problems

davej

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

Donald Lobo

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

davej

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

davej

Re: Alice in multi-org land - successes and problems

davej

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems

davej

Re: Alice in multi-org land - successes and problems

petednz

Re: Alice in multi-org land - successes and problems