I just implemented this on my site. One guy just complained he got 8 emails... and there was only one comment on the site. I am guessing that the comment author posted a comment (1 email) then spotted a typo and corrected it (2), then added an extra sentence (3), then added some missing punctuation (4)... and so on.

Is it possible to get the module to distinguish between genuinely new submissions (inserts into nodes, I guess) and mere updates of existing submissions (updates, I guess)? Maybe the user profile could have two check boxes, not one: "Notify me for new comments" and "Notify me for updates to comments".

It would make an otherwise excellent module all-but perfect!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Christoph C. Cemper’s picture

Status: Active » Postponed

I see where you coming from, but as you might have noticed, but it took 2 major versions to fix that hook-issue in the comment.module (see http://drupal.org/node/156475 ) and I'm not yet sure if it makes it into the drupal6 final core

that being said, I would expect the core coders to take another 2 major releases before adding any feature like this to the core - just to pimp such functions as comments

postponing this in favor of other issues

Junyor’s picture

Status: Postponed » Active

Drupal 7 development is open. How can this be solved?

greggles’s picture

I think this can be solved in comment_notify for 6.x (and even backport to 5.x...)

As soon as we have our own table (#232564: refactor data structure so core tables are not altered and move towards PostgreSQL compliance) we can add a column to it for "notified". When comment_notify finishes its job it can set that column = 1 for the comment id. Then when a comment comes through on "hook_publish" we check the notified column of the comment_notify table - if it's 1 we quit. If it's 0 we keep going.

greggles’s picture

Version: 5.x-1.x-dev » 7.x-1.x-dev

Although if it happens it will be for 6.x.

aclight’s picture

Status: Active » Needs review
FileSize
4.09 KB
4.13 KB

Here are patches that fix this problem for both the D5 and D6 version. Update functions are named assuming other patches are committed first, but might need to be renamed if that's not the case. I've only tested the D5 version of this on mysql, though the D6 version of the patch is quite similar.

greggles’s picture

Here's a slightly different patch.

1) Includes a fix for #374210: whenever a "reply to this comment" reply is reached that doesn't get sent, all sending breaks
2) Uses 6.x style db_add_field in the .install
3) Moves the query that updates the comment_notify to indicate that a notification has been sent outside of the while() loop. We need to mark this even if nobody gets a notification, right? I'm tempted to do it on insert...?

aclight’s picture

If you do it on insert then what is the point of even keeping track of whether notifications have been sent out for the comment? Don't we need to support the case where comments are moderated and we only send out the notifications when the comment has been published by the admin?

The patch looks good to me after a quick read through, but I haven't tested it.

greggles’s picture

Of course - that's a great point about needing to wait for the publish to happen.

greggles’s picture

Version: 7.x-1.x-dev » 5.x-2.x-dev
Status: Needs review » Patch (to be ported)

This is now committed to the 6.x branch - http://drupal.org/cvs?commit=178434

greggles’s picture

Status: Patch (to be ported) » Closed (fixed)

This module is no longer actively developed for Drupal 5. If someone wishes to take over as the 5.x maintainer I would consider it, but these days everyone should really upgrade to Drupal 6.x.