CiviCRM Community Forums (archive)

I've found spotty documentation on this, so I wanted to do several things with this topic:
1. report what I've found through wrestling with "reverse" OG sync and see if anyone can help elaborate,
2. suggest a way to improve the situation, and
3. see if anyone would miss removing a bit of already-disabled functionality

Currently

As things stand, if the CiviCRM OG Sync module is enabled, CiviCRM groups are created when OG groups are created, and each user's associated contact is added to the corresponding CiviCRM group when he or she subscribes to a OG group.  Deletion works the same.

However, out of the box, adding a contact to a CiviCRM group that's associated with an OG group does not subscribe that user to the OG group.  Likewise, removing the contact from the CiviCRM group does not affect the user's subscription to the OG group.

The files for OG sync are in two places:
drupal root..../sites/all/civicrm/drupal/modules/civicrm_og_sync/
drupal root..../sites/all/civicrm/CRM/Bridge/OG/

CRM/Bridge/OG/Utils.php begins with declaring two constants: aclEnabled = 1 and syncFromCiviCRM = 1.  However, the function syncFromCiviCRM( )--on which all the CiviCRM-to-OG stuff is conditional--only returns true if aclEnabled = 0 and syncFromCiviCRM = 1.  There's even a comment there saying "make sure that acls are not enabled".  I'm not sure why ACLs for CiviCRM OG groups and syncing from CiviCRM should be mutually exclusive, however.

Still, setting aclEnabled = 0 subscribes and unsubscribes users from OG groups as contacts are added and removed from the corresponding CiviCRM groups.  However, there is an unintended consequence, as I'll explain.

The Problem

There is a function groupAdd() in CRM/Bridge/OG/CiviCRM.php that adds new OG groups (called by hook_civicrm_post when CiviCRM groups are created).  Now, I don't think most people would want an OG group created for each CiviCRM group, but that's beside the point.  The real problem is that it creates a node of the type "og", whether or not there is an actual node of that type.  Moreover, it somehow gets called when syncing contacts that got added to CiviCRM groups.  It searches for the node ID and overwrites the node record to have the type "og".  If your organic groups are called something different, this causes all sorts of problems.

A Suggested Solution

First, nobody will be thinking to look in CRM/Bridge/OG/Utils.php to enable or disable OG ACLs and sync from CiviCRM groups.  These ought to be variables set in the Drupal variables table, editable from an admin page.

Second, I doubt that it's preferable in (m)any cases to have OG groups automatically created from CiviCRM groups.  This is the "feature" that's causing most of the trouble, and eliminating it should make the CiviCRM-to-OG sync useful for what I feel would be most use cases.

What Do You Think?

Does this make sense?  Does anyone use the automatic OG creation from CiviCRM groups?  I don't want to urge the removal of a feature people use.  On the other hand, I'd be happy to work on a patch get this working out-of-the-box for most people.

Also, I don't know why syncing from CiviCRM and ACLs from OGs should be mutually exclusive.  If you have an idea why, please explain.

Hi Peter,

Great to know.  Actually, most of the code for reverse sync is already shipped; it's just prevented from running because of that weird bit at the top of CRM/Bridge/OG/Utils.php where it enables ACL for OG and disables reverse sync if ACL for OG is enabled.

Andrew

I'm just looking at this for Drupal 7, and was wondering about the issue raised by andrewhunt

There is a function groupAdd() in CRM/Bridge/OG/CiviCRM.php that adds new OG groups (called by hook_civicrm_post when CiviCRM groups are created).  Now, I don't think most people would want an OG group created for each CiviCRM group, but that's beside the point.  The real problem is that it creates a node of the type "og", whether or not there is an actual node of that type.  Moreover, it somehow gets called when syncing contacts that got added to CiviCRM groups.  It searches for the node ID and overwrites the node record to have the type "og".  If your organic groups are called something different, this causes all sorts of problems.

Is this [still] an issue?

We are looking to reverse sync and create OGs for existing CiviCRM groups.  Anyone have experience with this?  Do you have to create the OGs manually and if so, are there any suggestion for how to let the CiviCRM OG Sync module know which OG relates to each CiviCRM group?

Thanks for any pointers.

Andrew

FYI - We are trying to refactor the OG synch module for D7

Hi Laryn - i will check with the team on Monday but from what I recall of the conversation, a couple of hours of walking through the code resulted in us basically confirming that reverse synch could work (and does) based on the existing code. But let me come back with a more technical answer.

i think my comment above still holds - reverse synching is already available as the code stands