Multi Org implementation ideas

Use Case 

Lets take a look at the US Political System. (and i think this is similar to PIRG / NZ GP / Canadian GP)

1. There is the National Purple Party. National has organized its core contacts into a few groups. Some of these contacts have been added at a National level while the rest have been added at a State/Local level (i.e. magically appeared in the DB).
2. There are 50 State Chapters that are part of the National Party.
3. Each State Chapter has further city and/or county chapters that feed into it. A State like California might potentially have 100 sub-orgs, while Wyoming might have less than 10 sub-orgs.
4. All the above orgs have "staff contacts" linked to the organization via relationships
5. For simplicity sake we will consider the following permissions only. We assume that a sub-org will never need permission for the parent org.

• Edit Contacts
• View Contacts
• Edit Contacts of Descendant Orgs
• View Contacts of Descendant Orgs

There are two potential ways of tackling this issue in CiviCRM currently:

Domain ID Method

Use the domain_id concept that is already built in. Each sub-org gets its own little silo of data and can adjust permissions as needed there for local admins. We then need to introduce the concept of a "multi-domain" civicrm setting, where the parent org can also view/edit contacts from its sub-orgs (i.e. from other silos). This change will require code changes in only a few key areas and is potentially simpler. Contacts are now always associated with a Domain ID. Thus a Contact ID by itself is meaningless. The main drawback of this scheme is that the same contact cannot belong to multiple domains.

ACL Permissioning

For an introduction and basic understanding of ACL's please read this blog post. You might also want to read our ACL wiki pages

The second approach is to extend ACLs to make them more generic and follow the multi org model. We keep the same key concepts as present in CiviCRM. We have organizations and groups.

We introduce the concept of ancestor for an organization. An organization can have one or more ancestors. We create a join table with two keys

We introduce the concept of ownership for a group. A group can have one or more organizations

 We can make the assumption that all public groups of a sub-organizations are inherited by the ancestor organizations.

We also introduce the notion of permission(s) to a relationship type. Thus, we can give the permission "Edit Contacts in Organization" and "Edit Contacts of Descendant Orgs" to the relationship type "Executive Officer".

How does this fit in with ACL's?

 ACL's in the simplest form basically give one or more contacts the power to execute a specific operation. So given a user, we need to find the permissions this user has. Since this is a common function, we need to make this relatively fast and avoid too many db queries etc. We could do a fair amount of caching here at some stage. In our current implementation, answering this questions is fairly easy and is done as follows:

1. What ACL group's does this user belong to
2. What is the collective permission of these ACL groups
3. Does the user have the permission in the above set to perform the operation (or for a search, the additional restrictive sql clause)

Note that we can cache the results from step 1 and 2 for each user and so this can be done only once and is relatively fast. The main drawback of the above scheme is its quite ACL intensive. i.e. you need a lot of ACLs to cover the national -> state -> local chapter above

In the new scenario in addition to the above, we will have to perform the following steps:

1. Get the permissions the user has via the relationship permissioning scheme above
2. For each of the orgs that he has permission on, get the groups and the sub-groups (depending on the permission)
3. Add these permissions to the set of permissions above

Note that we can also cache these for users and perform the above just once. This allows us to generalize permissions quite nicely and makes it easier to control who has permissioning based on the relationship in a very generalized manner

How does this fit in with smart groups?

To avoid smart group bloat, we would need to implement tokenized smart groups. Thus instead of creating 50 smart groups for each state, we create one "tokenized" smart group and send in the "State" value whenever we need to use it. Thus we'd create a tokenized smart group for state / county / province / city / electoral district etc. This also means we'll need to have a protocol of sending in the "token" values for each instance of the group.

This simplifies the model a fair amount, but i suspect might make implementation a bit more difficult. But something worth thinking about

How does SalesForce handle this

Here are some links for the relevant SalesForce documentation. Definitely worth a read

• Enabling Territory Management
• Managing the Sharing Model
• Roles