ACL's, Organic Groups and Multi-Org

This is being driven by a specific client's needs

Problem scenario

Client is structured as International Org -> Region Org -> Country Org -> Chapters. There are 3 regions and 70 countries. A few of the larger countries (5-8) have some smaller chapters associated with it. In total there are 100 groups. Each group has one or more administrators. The administrator of a group should be able to view/edit all contacts within that group and send broadcast mail to a subset of these contacts (e.g. all males in Paris). The administrator of a country has similar rights to everyone in that country and below. Similar rules apply for the region administrator and the top level administrator. Note that an administrator could have rights to more than one group.

Organic Groups

Organic Groups (OG) is a fairly popular drupal module. From the project page, organic groups can be described as follows:

Enable users to create and manage their own 'groups'. Each group can have subscribers, and maintains a group home page where subscribers communicate amongst themselves. They do so by posting the usual node types: blog, story, page, etc. A block is shown on the group home page which facilitates these posts. The block also provides summary information about the group.

Groups may be selective or not. Selective groups require approval in order to become a member, or even invitation -only groups. There are lots of preferences to configure groups as you need.

An administrator in OG is either the group 'owner' or 'manager'. OG does not have a concept of hierarchy. So for the above scenario, we flatten the hierarchy and create a flat one layer structure of all groups at the same level. A country administrator needs to be given administrator rights to EACH of the chapters in that country. A region administrators needs to be given administrator rights to EACH of the countries in that region.

OG and CiviCRM

og_civicrm is a contributed module (for Drupal 4.6, CiviCRM 1.4) that connects OG and CiviCRM. From the project page:

The OG_CiviCRM module integrates organic groups with CiviCRM groups. This is useful for groups that form organically on the web but need to be tracked for an organization. Once the group of web users are in CiviCRM they can used to do mailings, track address information, apply tags, and track activities of the members.

The module creates a new CiviCRM group for each new OG and use the module to keeps track. The groups are kept synchronized. If a user is subscribed to a group via Drupal's UI, then the user has already been subscribed on the Drupal side, and we will need to subscribe the user on the CRM side here as well. If an organic group is deleted the CiviCRM group is deleted.

This module thus keeps an OG in sync with a static CiviCRM group, i.e. a member of an OG is a contact subscribed to the synced CiviCRM group. Thus for our problem, we would have 100 CiviCRM groups with the same name to the respective OG. This module does not handle permissioning on the CiviCRM side (as such it ignores if a member is an 'admin' of an OG).

Extensions to the above model

To make the above module applicable to the current scenario, we will need to upgrade og_civicrm to use Drupal 5.2 and CiviCRM v1.8. We will also need to extend the module to create CiviCRM ACL for each admin. Here are the steps for various operations

Creation of an OG 'xyz'

• Create a CiviCRM group with the name 'xyz'.
• Create another CiviCRM Group 'xyz: Administrator'
• Create an ACL Role 'xyz: Administrator'
• Create an ACL GroupJoin record to link the CiviCRM Group 'xyz: Administrator' and the ACL Role 'xyz: Administrator'
• Finally create an ACL giving ACL role 'xyz: Administrator' permission to perform the 'Edit' operation on a Group of Contacts

Deletion of an OG 'xyz'

• Delete the ACL that gives ACL role 'xyz: Administrator' permission to perform the 'Edit' operation on a Group of Contacts
• Delete the ACL GroupJoin record to link the CiviCRM Group 'xyz: Administrator' and the ACL Role 'xyz: Administrator'
• Delete ACL Role 'xyz: Administrator'
• Delete CiviCRM Group 'xyz: Administrator'
• Delete CiviCRM group 'xyz'

Add/Remove a user 'abc' to OG 'xyz'

• Let 'cid' represent the equivalent contact id for user 'abc'. If no contact present, create one
• Add/Remove 'cid' to/from CiviCRM group 'xyz'
• If 'cid' is an OG admin, also add/remove 'cid' to/from CiviCRM group 'xyz: Administrator'

Promote/Demote user 'abc' as admin of OG 'xyz'

• Let 'cid' represent the equivalent contact id for user 'abc'. If no contact present, create one
• Add/Remove 'cid' to/from CiviCRM group 'xyz: Administrator'

Other Considerations

• CiviMail does not have any permissioning / partitioning with regard to mailings. We will have to introduce some sort of permissioning/partitioning scheme to make this useful. Ideally a "mailing" follows the same rules as groups. A person can see a mailing if they have rights to see ALL the groups who are part of the mailing.
• CiviMail also needs a rich text editor for which a patch has been submitted and we are integrating it into the 1.8.uas branch
• We expect to do all additional CiviMail work and add enhanced support for UAS batching and other issues in the svn branch: http://svn.civicrm.org/branches/v1.8.uas/

Time estimates (very rough estimates)

• To upgrade and get og_civicrm to current OG and CiviCRM versions: 40 hours
• To add ACL support: 60 hours
• CiviMail enhancements: 50 - 100 hours (depending on whats needed etc)