The subscription email comes in perfectly.. but .. it also emails you *each* time the person edits their comment / post.

I would prefer to only email a user 1 time per 'subscription' until they revisit the site.

This is a very 'common' manner in which sites are configured..

Users always appreciate it when the site contacts them in an intelligent manner VS sending them tons and tons of emails.

Much more likely to get them all deleted, annoy them or even worse - they might unsubscribe or leave your site.

Comments

leoklein’s picture

leoklein commented

+1 on this.

The reason why this is important is that the author of the post may be "updating" it with something as trivial as a spelling correction.

kmillecam’s picture

kmillecam commented

+1 from me too.

Sometimes we go into a document 10 or 15 times before it's "perfect". With the current code, my users get 10 or 15 notifications for each node (because of our crazy editing style).

Thanks,
Kevin

mcsolas’s picture

mcsolas commented

I figure that editing style is very common.. or at least a few : )

Any word on progress. When I did something similar I called the column "Notified" & when the email fires, you have to set it to 0/false for that users|subscription|thread relationship.

kimangroo’s picture

kimangroo commented
Title: Sending only 1 email per subscription.. resets when a user logs in » +1

+1 here as well. Actually I though the subscription module did that already! I've only just started using it now. On a busy site, repeated emails would have me running away from that site as fast as possible.

salvis’s picture

salvis
he/his
commented
Title: +1 » Sending only 1 email per subscription.. resets when a user logs in

subscribing

(please don't change the title!)

kimangroo’s picture

kimangroo commented

Oops sorry! To be honest I don't really know how this section of the site works... What's with the priority, assigned and status stuff... I know for me the priority is very high! ;)

Anonymous’s picture

Anonymous (not verified) commented

Isn't this here a duplicate of the following:
http://drupal.org/node/76468

I know that it only relates to 4.7, but there is a patch mentioned for Drupal 5.1...

Anonymous’s picture

Anonymous (not verified) commented
Priority: Normal » Critical

I have tried the patch, but it did not work (at least not on my installation). This is very unfortunate as there seems to be a lot of demand for this or a similar feature - compare the following postings:

http://drupal.org/node/86741
"Currently users can get bombarded on busy sites."

http://drupal.org/node/76468
"If the editor has 20 goes at updating a page because he is not quite sure how to do it, members ger 20 notifications and then write to me to complain!"

http://drupal.org/node/142454
"...would be great so it reduces the amount of mail load."

To me this seems like a very important feature and you don't need busy sites to make this a big problem. Even 10-15 daily comments on a thread (=10-15 emails where just one would have been enough) are enough to really annoy users. I would love to do the programming, but my PHP is very limited. Anything else I could do to make this happen?

mcsolas’s picture

mcsolas commented

Strictly from a scale factor like you say - I was quite surprised there has been no cut off switch installed.

That cut off is why the drupal forums themselves probably dont allow people to subscribe to threads.

I figure the subscription system also can reduce the load on the server.
1. people go directly to the page they want to see
2. they only come back when they need to

Presently, without this, you have to visit your own tracker page. It has to scan then entire drupal database to check if a thread has been updated for you. That page must take massive amounts more processor cycles to calculate...

chx’s picture

chx commented
Version: 6.x-1.x-dev »
Status: Active » Fixed

You can now easily set up sending intervals.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Active

Thank you for the work on this - it looks really helpful and my users will love this feature. Nevertheless, it does not really fix the bug - to quote mscolas

I would prefer to only email a user 1 time per 'subscription' until they revisit the site.<?blockquote>

Currently, if you have set the system to "immediate" notification, you will get new messages whenever there is a new node/comment and if there are 20 in an hour, well, you get twenty in an hour. There may be a use case for this, but there definitely is one for the suggested solution: send out 1 email notification and stop sending further notifications until the user has logged in and look at the node. You may want to be immediately notified about new updates, but you would not want to receive 120 emails if you happen to take part in an active discussion.

Setting this to "daily" does not really solve the problem - you won't get immediate notification, but if you are away for two weeks and subscribed to several active discussions, you will nevertheless find dozens of emails where three or four might have been enough.

jaysmall’s picture

jaysmall commented

Here's a slightly different use case:

Site contains events associated with venues. Venues are categorized in a taxonomy.

I want users to be able to, in effect, subscribe to specific venues by selecting their taxonomy terms. Then they'll be notified either when we update the venue details OR post new events associated with a venue, because we'll associate both with the venue's taxonomy term.

Users could, obviously, subscribe to more than one venue term. And we could wind up adding many events every week -- again, the potential for bombarding users is very real.

We don't expect lots and lots of edits of the same nodes, but lots of time-sensitive new node creations. Also, we'd like the users to have a predictable volume of incoming messages from the site.

Ideally, users could say, "I want to receive only one message per [day | week | month] with all my current notifications from this site rolled into one message at the time of the send."

Possible? Impossible? I'd sure love to have access to that kind of "My Agent email" capability within Subscriptions.

jaysmall’s picture

jaysmall commented

I guess I should clarify the difference between the original feature request and what I'm asking for.

Original request: limit to one e-mail notification per *subscription* (either via cron or instantly when subscribed content is updated) until user logs in and checks the updated content.

My request: one e-mail notification per *user* per selected interval containing all notifications from all subscriptions for that user. Doesn't reset on log-in because the user requests notifications on a selected interval (1x day|week|month) of anything new since the last send, not since last log-in.

Make sense?

Anonymous’s picture

Anonymous (not verified) commented

Your description does make sense, but I would suggest having that as a separate feature request - as you say yourself it is not entirely what the original posting was about.

salvis’s picture

salvis
he/his
commented
Priority: Critical » Normal

My request: one e-mail notification per *user* per selected interval containing all notifications from all subscriptions for that user. Doesn't reset on log-in because the user requests notifications on a selected interval (1x day|week|month) of anything new since the last send, not since last log-in.

This is essentially how it's supposed to work now. Please open a new issue if it doesn't.

The present feature request is about a different strategy, which might also be useful.

jaysmall’s picture

jaysmall commented

Upon further testing, Salvis, you are correct -- my use case is the way the 2.x version appears to work now. Thanks for the responses!

mcsolas’s picture

mcsolas commented
Title: Sending only 1 email per subscription.. resets when a user logs in » Any updates to the status of this request?

I would contribute code-wise but I am completely at a loss when dealing with php. Im a coldfusion coder / application designer who at one point downloaded every open source forum application I could find, tore them apart, analyzed the db structures and went to design a forum system using only 5 tables (ran in coldfusion). I know what Im talking about here when it comes to the design level.

Without these email notifications, after posting requesting help on issues I really need to solve, I find myself pinging tracker 5-10 times a day. I feel bad even, because each page load has to scan the entire node table.. takes quite a while sometimes, so I know I am 'wasting' precious server resources, but I also need to solve my problems and keep working..

The thing is that you have no choice here but to rely on tracker to keep track of drupal org site activity.
(slightly off topic - check my posts re: tracker, there is some pretty crucial changes that could be made there as well)

imo those tracker queries are a massive waste of server resources because in most cases, I would have either
a. not visited the site ( no email means no threads updates, keep waiting )
b. gone directly to the node in question, skipping the full table "tracker" query

This cutoff switch isnt hard to implement. It will require a single new column in the "subscriptions" table "notified" which is either {true|false}.
When an email fires "onNodeUpdate", the row is set to true.
When the user returns and creates a new session, all rows set to that users id are set to false

Please if anyone has questions about how and where the logic goes, I offer my time to help you sort this out, just ask I will be most happy to try and make even more specific suggestions ( although remember, im not familiar with php, I can only help at the design level ).

mcsolas’s picture

mcsolas commented
Title: Any updates to the status of this request? » Sending only 1 email per subscription.. resets when a user logs in

Didnt mean to change the issue title

oc’s picture

oc commented

+1 this is a good idea, to allow a lower traffic notification of just a single update before the user logs in again.

gustav’s picture

gustav commented
Version: » 5.x-2.0-beta9
Status: Active » Closed (duplicate)

There now is a patch for this at http://drupal.org/node/210548