A user discovered that og2list always sends the first revision of a node, even if that node is changed before it's published.

The reason is that og2list_send_mail is inserting the message body right when hook_nodeapi() is called for the insert. If the author unchecks "published" then the node isn't sent out right away. If the author changes it and makes a new node_revision, the wrong body is in the DB.

The solution is to have mail-out.pl collect the current revision's body when the node is being sent. The $body field that is inserted into the DB is just made blank in the attached patch. Later it will be used to send in a footer (and possibly renamed). In my private version I construct a group footer in og2list_send_mail and I'm sending it through that $body field. (I plan to create a patch for the group footer links sometime this winter!)

Anyway, the attached patch fixes the problem. A blank string is sent in in place of $body, and then mail-out.pl has a modifed get_content_stmt query that joins to node and node_revisions and gets the correct body.

If someone could test this it would be great. Here's how to replicate the problem / test:

1. create a new forum topic in an og2list group. un-check the published box under "publishing options". Make the body test something distinctive like "first revision - not published!"

2. After submitting you will see the post in view mode, now press edit and change the body text to "second revision - published!" and check "published" and "create new revision" under Publishing Options, then submit.

3. Run mail-out.pl twice if it's not automatic by cron job

4. Check and see what was e-mailed out by og2list. Without the patch applied you should get the first revision. With the patch applied you should correctly get the second revision.

Comments

damien_vancouver’s picture

Status: Needs review » Needs work

we encountered some problems in beta testing of this patch, where the module started sending out incorrect node bodies. This didn't occur in the initial testing in a test group. I will attempt to replicate using a backup of the production site that had the problem, then submit an updated patch.

damien_vancouver’s picture

OK, finally I have got this fixed and working properly in our private version.

It is nearly impossible to pull the correct revision content from the perl, because without the Drupal API at your fingertips rendering the node if it's a custom content type is right out, and also constructing accurate footer links is also right out (There are no footer links in the CVS HEAD version... yet ;)

Anyway I expect to have this backported by the end of this week (or at least by christmas), then it will be ready for testing.