The enclosed patch makes og_civicrm compatible with Civicrm v.1.4BETA-rev4915M, which became available today; you'll need this version or later for the patch to work for you.

The patch is for Drupal 4.6; it may work under 4.7, but has not been tested at all in that configuration.

Major changes in this release:

  • Groups now mirror from CRM into Drupal and Drupal into CRM.
  • Contacts/users can be added or removed both by using Organic Group's subscribe/unsubscribe or CRM's add/remove contact functionality.
  • This release has been tested with the CRM tables in the same DB as Drupal, and also in different DBs. Both work.

This code should be considered experimental, and I don't really recommend trying it out unless you're a developer who's pretty familiar with both CiviCRM and Organic Groups: you'll need to configure CiviCRM 1.4 manually, for one thing.

A full port to 4.7 is in progress, which will involve major feature changes. If you're not a developer, you'll probably be happier with that version.

If I haven't scared you off yet: I'd love to get any feedback on behavior, bugs, and feature requests. Please post them against this issue.

Thanks,
Rob Thorne
CivicSpace Labs/Torenware Networks

CommentFileSizeAuthor
#1 og_civicrm_for_civicrm_14.patch.txt18.25 KBTorenware

Comments

Torenware’s picture

Torenware commented
StatusFileSize
new og_civicrm_for_civicrm_14.patch.txt18.25 KB

Hm... guess the patch didn't get uploaded :-(

Let's fix that.

gerhard killesreiter’s picture

gerhard killesreiter commented

Rob, I suggest you take over maintainership for og_civicrm.

Torenware’s picture

Torenware commented

Gerhard --

Be happy to. If you have time to look the patch over, thanks for that as well.

Anything you or I need to do formally to make it official?

Thanks,
Rob

killes@www.drop.org’s picture

killes@www.drop.org commented

No, just commit it, nothing formal needed.

I don't agree with the coding style in places and would still want to keep the db_set_active calls...

Torenware’s picture

Torenware commented

I'll check a bit on coding style. There are two reasons I took out the db_set_active calls:

1) I've been testing on a dual database install (one for civicrm, one for Drupal), and it "just works" without the calls.
2) If it does turn out to be a problem, that's a serious CiviCRM bug, and it should get fixed. Might as well make it surface ASAP.

Thanks,
Rob

moshe weitzman’s picture

moshe weitzman commented

you need db_set_active() when the two databases differ in db server or credentials. the prefixing trick is powerless in this situation. db_set_active() is more flexible.

Torenware’s picture

Torenware commented

Moshe,

The main issue is that the connection with CiviCRM is completely separate, and all access to it is via PEAR libraries. No Drupal database code is used.

If you read the implementation of db_set_active, even if it was the right thing to do, there really isn't any way that the call would affect the connection used by PEAR.

Torenware’s picture

Torenware commented
Status: Needs review » Fixed

Patch has been checked into HEAD and branch-tagged as DRUPAL-4-6.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)