As of CiviCRM 2 the activity_history API no longer exists. Modules are instead encouraged to create a new tab in civicrm and display their own history tables. This patch provides this by adding a column to {send} and {send_recipient} for civicrm contact_id. During update.php existing records are populated with a contact_id. This patch should probably work for versions as far back as CiviCRM 1.7 (which must be about 1.5yrs old).

This is my first draft, by the time I get this to development ther'll probably be a few changes/fixes.

CommentFileSizeAuthor
#7 send-5.x-1.0-civicrm.tar_.gz29.86 KBsdybiec
#6 send_civicrm_2.diff21.44 KBdalin
#4 send_civicrm_2.diff21.34 KBdalin
send_civicrm_2.diff21.2 KBdalin

Comments

allie micka’s picture

allie micka
she/her
commented

I'm no longer actively using CiviCRM, so it doesn't make much sense to keep the code inside of send proper. I think it makes more sense to split the CiviCRM stuff into a separately-mantained module, using send's tables and/or API. If you have the time and inclination, I'd love that! Otherwise, I'll try to make a basic module next time I spend some time working with Send.

Thanks!

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented

Unless send module fired a hook when a mail was sent I'm not sure how I would have this code in a separate module. The existing code (and my patch) looks up contact IDs during the sending process and adds them to the main INSERT statements.

As for the API method my rough understanding of the Send API is that it would require duplicating the entire send-to-friend code with a few extra lines for the civicrm calls.

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented

I should note that since one of our major clients relies heavily on this functionality, Advomatic is willing to help maintain the civicrm sections on an ongoing basis.

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented
StatusFileSize
new send_civicrm_2.diff21.34 KB

Here's a slightly updated patch. Just a few tweaks to send_update_4().

I was also thinking that an alternative method for doing this whole CiviCRM thing might be to have a separate module that uses hook_form_alter to add some extra hidden fields and another submit handler. This module could then store the contact_ids in a separate table that would have a one-to-one relationship with {send_recipient}. However this is currently not possible since {send_recipient} does not have a primary key.

sdybiec’s picture

sdybiec commented

To which version do I apply this patch? The patch utility fails against the current and development releases.

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented
StatusFileSize
new send_civicrm_2.diff21.44 KB

Whoops. I was developing against an old dev release. Here's a new patch against send 5-1--1-0 (which looks like is the same as the MAIN branch).

sdybiec’s picture

sdybiec commented
StatusFileSize
new send-5.x-1.0-civicrm.tar_.gz29.86 KB

Awesome. Your patch worked beautifully against the 5.x-1.0 released code. My 'send to a friend' function is now working again with CiviCRM v2!

Here's what I did:

1, applied the patch the 5.x-1.0 code
2. tarred/gzipped the new code base and uploaded to my site (patched module is attached)
3. replaced my current 'send' module directory with the new version
4. went to http://mysite.com/admin/build and followed the link to update the db
5. here's the output of the update process:

The following queries were executed
send module
Update #3

* ALTER TABLE {send} ADD contact_id INT
* ALTER TABLE {send} ALTER contact_id SET default NULL
* ALTER TABLE {send_recipient} ADD contact_id INT
* ALTER TABLE {send_recipient} ALTER contact_id SET default NULL
* ALTER TABLE {send} ADD INDEX index_send_contact_id (contact_id)
* ALTER TABLE {send_recipient} ADD INDEX index_send_recipient_contact_id (contact_id)
* ALTER TABLE {send_recipient} ADD INDEX index_send_recipient_sid (sid)

Update #4

* UPDATE {send} SET contact_id = 102 WHERE uid = 1 AND mail = 'joe@data.com'
* UPDATE {send} SET contact_id = 0 WHERE uid = 0 AND mail = 'jimb@slow.com'
* UPDATE {send} SET contact_id = 159 WHERE uid = 11 AND mail = 'ray657678@aol.com'
----- many of these ----
* DELETE FROM civicrm_activity_history WHERE activity_type = "sent" OR module = "send"

dan90’s picture

dan90 commented

dalin, that's awesome work. However, it looks like your patch only works for shared drupal/civicrm dbs, not separate ones; thus on my separate DB site, for example, the update.php script gives us a whole bunch of error messages like

user warning: Table 'drupaldb.civicrm_activity_history' doesn't exist query: update_sql DELETE FROM civicrm_activity_history WHERE activity_type = "sent" OR module = "send" in /var/www/cpd/includes/database.mysql.inc on line 172.

However, it sounds like our upstream maintainer is no longer interested in the Civicrm integration anyway... What's the status here? How do we all feel about continuing to contribute patches to the module if they won't be integrated?

allie micka’s picture

allie micka
she/her
commented

For the record, I'm planning on splitting the CiviCRM functionality out of send. I'm not actively using it, and there's not reason it can't be in a contributed module.

I'll try to work on this as I have time, but would appreciate a hand. Meanwhile, *please* don't make changes to send's tables for this! Users won't have any upgrade path if they apply this patch.

Can you use a sid or rid foreign key somehow?

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented
Status: Needs review » Needs work

@Allie I aggree, having it is a contributed module would probably be best. However in order for that to be possible {send_recipient} would need a primary key. Without that there is no way to relate sent messages to civicrm contacts. I think a simple autoincrement integer would be best.

Once a primary key is in place, then the contributed module could use form_alter to add a second submit handler, and use that to insert a record into its own table.

allie micka’s picture

allie micka
she/her
commented

@dalin that sounds like a reasonable proposal.

In the short term, would this help? http://drupal.org/project/civicrm20compat

allie micka’s picture

allie micka
she/her
commented
Status: Needs work » Active

I'm not sure whether or not to close this -

I have removed the CiviCRM functionality from the module, and I have added an auto increment to the send_recipient table. I'd still like to see some of this functionality return via a 3rd party, so perhaps this is closeable when that module hits CVS?...

allie micka’s picture

allie micka
she/her
commented
Status: Active » Closed (won't fix)

I have just committed a change that allows any module to implement hook_send_send on message delivery. I'm going to call this good enough! If there are any CiviCRM users out there who'd like to know what their users are doing, a separate module would be nice.