I'm using the Workflow module for a content type that requires a few workflow states (draft, review, approved). A trigger is set up to perform the following actions when the workflow state moves to 'approved': 1) Publish post, 2) Save post

The content type is also set up to send notifications to subscribed users (through the Notifications set of modules) whenever the content is published.

Unfortunately, the workflow module causes node_save() to be invoked twice whenever the workflow state is changed. This would not normally be a problem except that because the Content Notifications module is set to a weight of 100 in the system table by its installer, notifications_content_nodeapi() gets invoked twice, but only after *both* calls to node_save() have initiated. This 'race condition' causes the logic to determine the published/unpublished status of the node in notifications_content_nodeapi() to completely fall apart, resulting in the module treating the single change in workflow state as two separate 'publish' events. Two entries are created in the notifications_queue table with separate eids, and thus, two notifications are sent to each subscriber.

One solution I've found so far is to up the weight of the Workflow module to 100 as well, although I'm not sure what the implications of that may be. Would be nicer to have a more robust check in notifications_content_nodeapi() for this kind of situation.

Comments

mrtoner’s picture

mrtoner commented

Mmm. I wonder if this is the same issue I'm facing, but with the Rules module? I'm seeing exactly what you describe -- two notifications sent per node status change. Digests, too, receive two events per change.

Would love to get some feedback from Jose.

Update: Yes, that appears to be the problem. Changing the weight of Rules to 100 stopped the duplication of notification messages. Still would like to know if this is an issue that needs to be addressed with Notifications or with Rules/Workflow.

jose reyero’s picture

jose reyero commented
Status: Active » Patch (to be ported)

Interesting one.

Yes, I think we should handle this in case some other modules do this weir things too. I've added a static variable in notifications_content_nodeapi() to keep track of these nodes.

Let me know whether this works so we can backport it to 4.x branch.

jose reyero’s picture

jose reyero commented
Status: Patch (to be ported) » Postponed (maintainer needs more info)

Forgot to mention that if no one can confirm this works I'll just roll back the patch *before* next stable release.

mrtoner’s picture

mrtoner commented

Sorry, Jose, are you saying that you've put the fix into 6.x-2.x-dev? I'm not clear on what "patch (to be ported)" means.

riverfr0zen’s picture

riverfr0zen commented

This is a major problem. You can't just 'roll back the patch' without testing it out properly in the 'field'.

jose reyero’s picture

jose reyero commented

I cannot let the patch into the stable release without testing it out properly.

Here's the patch btw, http://drupalcode.org/viewvc/drupal/contributions/modules/notifications/...

zeezhao’s picture

zeezhao commented

subscribing, as seen something similar with a custom module, but using notifications 4.x dev
edit: Jose - I also checked admin/messaging/subscriptions and there are no duplicates but email goes out twice

zeezhao’s picture

zeezhao commented

Jose - I applied the patch to version of 6.x-4.x-dev from May 28 which I currently have installed. Its seems to do the trick.

But please confirm that the patch can be applied to that version of notifications_content.module 1.4.2.9.2.36.2.18.2.23 which is the one in there.

Will await new 4.x-dev. Thanks

jose reyero’s picture

jose reyero commented
Status: Postponed (maintainer needs more info) » Fixed

Ok, this has been committed to 2.x and 4.x

Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.