Torenware Networks

Note: currently this feature is partially broken, since OG has changed substantially since I did the patch, and I haven't been able to keep up. If you're interested in this feature and can support the work financially, please contact Rob using my Drupal.org contact form.

Organic Groups support is actually pretty simple, although it does require a patch to og.module.

When an admin creates an organic group, there's a bit of additional UI towards the bottom of the form that creates an option to link your organic group to a CiviCRM group. If you don't link to a CiviCRM group, your group is an ordinary organic group. If you link, then any contact in the linked group is subscribed to the Drupal organic group just as soon as the user logs in. If the contact is matched to a new Drupal user, the Drupal user does not even have to exist when the organic group is created.

To make this work, I needed to patch og.module to extend Moshe's hook_og: I need to get in some code after organic groups starts loading its user information, but before it sets up $nod->og_groups, which is the list of organic groups the user belongs to. The patch is described on Drupal.org.

Moshe has not to date accepted the patch, so if you need to use my organic groups code, you'll need the patch. I'll keep an updated version of the patch attached to this page for now; hopefully if enough of us need it, we can get the patch in eventually. For now, I'm using CVS revision 1.50, which is a few behind; I'll update periodically as needed.

How Is This Different From og_civicrm?

Organic Groups support owes a fair bit to Gerhard Killesreiter's og_civicrm.module, but works a little differently. Both Killes' work and mine link a Drupal organic group to a CiviCRM group, but having used og_civicrm in a demo application I've spent a couple of months on, I've found it has several significant limitations:

• In og_civicrm, all organic groups are mirrored as CiviCRM groups, and all CiviCRM groups are mirrored as organic groups. In applications where essentially all of your contacts are also web users, this is not a bad scheme. But for many CiviCRM applications, you will likely have a couple of dozen of actual web users, who are working with as many as a quarter million contacts: this is the typical set-up for people who are using CiviCRM in political/voter database type applications.
• I've found that in CiviCRM, the best way to use groups is as a way of organizing contacts, and controlling access to them. Using all groups as organic groups tends to defeat this.
• You end up with a lot of organic groups that have no real use in Drupal, and a lot of CRM groups that don't make much sense except as lists of subscribers.
• Direct mirroring limits you to static CRM groups; there's no way to take advantage of CiviCRM's "smart groups
• Two-way mirroring means that Drupal hooks are called by CiviCRM hooks and visa versa, and a lot of the code in og_civicrm is there to prevent infinite loops and deadlocks. Nasty.

For all of these reasons, a little more UI led to a much simpler design.