Hello,

A friend just posted a comment to my post, and another 5 people replied afterwards - she got 5 notifications next time she checked her email.

Is there a way to do a check if a user has read any of the comments, and if they didn't, not to send them any more notifications about that post?

There was some talk about it here, but it's the older version: http://drupal.org/node/76468

Thanks,
Andrey.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

salvis’s picture

No, there's no such feature.

However, the behavior depends on how often your cron runs, and she can increase the Send Interval (depending on what you offer).

All pending comment notifications about the same node are merged into one email whenever one is sent.

mr.andrey’s picture

The following patch will make subscriptions module not send any more notifications until the user has read the post. This solves the problem in my original request. I think it's an essential feature, and would love to see it implemented in the future releases of the module.

I welcome any feedback.

Best,
Andrey.

ajwwong’s picture

thanks for doing this. this patch was what i needed in order to upgrade to 5. i'll test it as soon as i can!

gustav’s picture

Title: Bombarded with notifications - alternative. » Do not send any more notifications until the user has read the post
Version: 5.x-2.0-beta7 » 5.x-2.0-beta9
Category: support » feature
Status: Active » Needs review
mr.andrey’s picture

Here is an updated version that adds the following checks:

if comment post & new comment > 1 - no send
if comment update - no send
if node update & new comment > 1 - no send

What I would love to implement is also this:
if node update > node was unread by user before - no send

Any ideas?

Thanks,
Andrey.

mr.andrey’s picture

FileSize
2.7 KB

I just downloaded the beta12 and it seems to not have this feature implemented yet. As some things have changed, here is an updated version of this patch.

Best,
Andrey.

salvis’s picture

Version: 5.x-2.0-beta9 » 5.x-2.0-beta12
Status: Needs review » Needs work

Something like this might come in as an option, certainly not as THE standard behavior. IOW, it definitely needs work. However, I don't actually understand what you're trying to do (#5 is too cryptic). I understand your general idea, but we'd need to discuss your strategy for accomplishing the goal first.

However, note that it's awfully late to start pushing this again. There hasn't been overwhelming interest in the past, and I'm not convinced that this is a reason for delaying RC1.

dwrunyon’s picture

Hello again salvis!

I agree that it shouldn't necessarily be the "standard operation", but I would like to add my voice of interest in the option, though I do not intend any pressure. Again, thank you so very much for what you've done already!

mr.andrey’s picture

Hi there Salvis,

I'm not too attached to having it implemented. It already works fine as a patch, and it's just an extra step when I'm upgrading.

I'll try and translate the #5 comment.

Do NOT send notifications:
if (comment is being posted) and (there is a new/unread comment already)
if (comment is being updated)
if (node is being updated) and (there is a new/unread comment already)

The one more thing that is not in a patch that I would like is this:

Do NOT send notifications:
if (node is being updated) and (node is unread by user)

This particular rule is for when someone decides to edit the node multiple times and people with no-digest options get flooded with notifications. For now I have "on update" notifications turned off by default, so this likely won't happen often.

If this patch gets implemented as an option, that's great, but I'm fine with using it as is.

Please let me know if you need any more clarification on anything.

All the Best,
Andrey.

salvis’s picture

@dwrunyon: I don't see registering your interest in a proposed feature as pressure at all. On the contrary, if you have an opinion for or against a proposed feature, and maybe even a use case to back up your opinion, that helps to guide the process and clarify the need.

dwrunyon’s picture

I'm just trying to be sensitive to the fact that YOU do all the hard work and I just sit back and enjoy the benefits!

As for a use case, I do not have one specific to your module, but I know what I myself like when I am subscribed to say an SMF, phpBB, vBulletin forum thread. As an end user myself I desire to only be notified of the first comment *after* mine until I revisit, and as an administrator of a website I would like to offer my users the same option that I myself would desire if I were them.

I would definitely say that if it's a doable thing and not too much trouble, it would very much be a logical option to offer, and I would dare say that it would be the option most chosen by end users, whereas right now I kind of think the digest mode is most to my liking because it is the closest thing to it.

Really it's just a matter of not wanting my website's notifications to become an annoyance to my users, but still giving them the number of updates they would like.

salvis’s picture

@dwrunyon: Thanks for expanding — pretty convincing...

A key phrase that jumped into my eyes is "the option most chosen by end users". This begs for more configuration options...

@mr.andrey: Thank you for your clarifications.

On my sites I always send full nodes and comments, so that users don't need to visit the website, unless they want to post, but I know that for other admins drawing users back onto the site is a prority.

I clearly see the benefits and your criteria make sense, but they're still somewhat arbitrary. I think this needs some more work, and we're a bit late in the development cycle, so I'll just add support for an $event['nosend_uids'] list. Then we can have an optional add-on module that populates the list in hook_subscriptions_queue_alter() and maybe exposes some configuration options.

salvis’s picture

Here's a patch for subscriptions.module that will be in the upcoming RC1, as well as the new subscriptions_reduce_content_queue module, a small module with the code from #6.

I've tested the interface, but I haven't tested subscriptions_reduce_content_queue.module, so I can't say whether it works or not. This is just a repackaging of #6.

mr.andrey’s picture

Hi Salvis,

I just installed the module and did some tests:

New Blog by user A - user A and B are subscribed.
- User B posts a comment :: notification to user A sent
- User B posts another comment before user A reads it :: notification to user A NOT sent
- User B edits a comment that user A already read :: notification to user A NOT sent
- User A updates the node :: notification to user B sent
- User A updates the node again before user B reads it :: notification to user B sent (ideally this would NOT be sent)

All seems to work just like the patch in #6.

Thanks,
Andrey.

salvis’s picture

Version: 5.x-2.0-beta12 » 5.x-2.0-rc1
Status: Needs review » Needs work

Ok, thanks!

I'm changing this to back to CNW because it needs additional features.

robotjox’s picture

hello, I am in real need of this functionality, but it simply doesn't work at all for me. Maybe I've done something wrong?

If a user subscribes to a forum topic he will get notifications every single time someone comments on it - no matter if he never visits the page.

I would like him to be only notified once and then not before he visits the topic again. Is this not the way this patch and mini module should work?
I've tried changing all imaginable settings, but no luck :(

Hope you can help, thanks!

robotjox’s picture

bump - can you confirm if this patch currently works?

salvis’s picture

No, I can't confirm either way.

mcsolas’s picture

I just found the beta for drupal 6.

moving to that thread

http://drupal.org/node/273505

kecinzer’s picture

It is possible to add this feature to 6x version?

salvis’s picture

Sure, but it's unlikely, since no one bothers to provide feedback, testing, patches.

vuil’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

I set the issue's status to Closed (outdated) of non-activity since 2008.