I’ve noticed under Admin|Emails|Sent that a digest email did not go out to users, but they did all get an email for user_watching_first_post (per a preset default.)
I’ve verified that it’s not the case that these users have visited recently, are past the “suppress digest email after days” setting, or have changed their email preferences.
Is it correct that a notification email is treated as user activity, causing the digest to be skipped? If so, it’s not the behavior that I expected…
We’re using “watching first post” for a specific tag to notify users of high-priority topics, but we still want them to get the regular digest of other forum activity.
This is pretty central to our vision — I’d welcome any input on how to make it so.
So it’s the case that getting an email notification about a topic keeps the topic from showing up in the summary? It makes sense that you’d not want to get in the summary a message that you’d already had emailed to you another way.
It is much more than that. Getting an email notification seems to completely reset the counting such that no topics older than the notification get into the summary. This has always irked me.
Basically, if the email-notified punter does not visit the site, there is zero exposure of any topics between the previous summary and the last email notification. And it makes the site look much quieter than it really is when a summary finally squeaks through.
I’d like to see it being as you suggest, where only the notified topics are suppressed in the summary for users who receive an email notification but do not visit the site. That would be a vast improvement for sites who do quite a bit of default watching!!
Thanks for confirming this, Nathan. Yes, a digest was not sent despite other new eligible topics.
If the digest only avoided duplicating the otherwise-notified topic, that would make sense, but what it’s doing really seems like an oversight or a bug that’s quite counterproductive.
@pfaffman - does this sound like a rule that could be hacked somehow? Or would it need the attention of the devs?
It would take a plugin. I wrote one once that at least at one time purported to “adds the number of new posts to summary/digest email in the 3rd position (usually where new users is).” So it changes just that header at the top of the page.
It overrides that whole template, so that’s a potential solution.
On further thought, this really feels like a bug and not something to hotwire with a plugin. I’ve gotta believe the behavior is not intentional.
Site_settings include options for suppressing the digest, but none relate to other email notifications:
suppress digest email after days
digest suppress categories
digest suppress tags
More importantly, the user preference for Emails|Activity Summary is: “When I don’t visit here, send me an email summary of popular topics and replies.” – Yes or no, period. No relationship to Tracking emails is indicated.
Based on these settings, users should expect the Activity Summary setting to apply as described, and independently.
Suppressing notified topics from the summary digest would be great, but I’d consider that a luxury. Just making the digest unaware of Tracking email notifications would bring it line with expectations.
Wading in over my head here, but out of curiosity I’m looking at code on Github…
In the digest section of app/mailers/user_notifications.rb, topics_for_digest are sought based on a min_date that considers user.last_emailed_at
line 227:
min_date = opts[:since] || user.last_emailed_at || user.last_seen_at || 1.month.ago
# Fetch some topics and posts to show
digest_opts = {
limit: SiteSetting.digest_topics + SiteSetting.digest_other_topics,
top_order: true,
}
topics_for_digest = Topic.for_digest(user, min_date, digest_opts).to_a
if topics_for_digest.empty? && !user.user_option.try(:include_tl0_in_digests)
# Find some topics from new users that are at least 24 hours old
topics_for_digest =
Topic
.for_digest(user, min_date, digest_opts.merge(include_tl0: true))
.where("topics.created_at < ?", 24.hours.ago)
.to_a
end
(Edit: I see last_emailed_at is also referenced in app/jobs/scheduled/enqueue_digest_emails.rb and spec/jobs/enqueue_digest_emails_spec.rb among other things.)
This makes me think a digest is simply not generated for users whose user.last_emailed_at is too recent.
I haven’t been able to discern what emails count towards last_emailed_at. Evidently it includes notifications based on Tracking settings, but what about private messages, etc…?
Shouldn’t the digest only be concerned with user.last_seen_at ?
Currently when mailing list mode is enabled—at least at the user preference level (see following post)—the interface makes it clear that digest settings are overridden.
So maybe the only thing to add would be a “send always,” e.g:
Activity Summary:
[ ] Always send me an email digest
[ ] Only send me an email digest when I don’t visit here
(Drop down): every 30 minutes | hourly | daily | weekly | every month | every six months
But I’d see the “always” option as a nice-to-have. Just making the digest independent of other emails would seem to make it work as expected.
(Side note: if I had a large forum, I might wish for the available timeframes to be configurable by admin. Too many people choosing “always send… every 30 minutes” could run up email charges.)
This is secondary to my reported issue, but relates to Sam’s concern about Mailing List Mode vs. Activity Summary…
Interestingly, when admin enables “default email mailing list mode” and “disable mailing list mode,” (Scenario A) it’s not clear what happens. The user doesn’t see anything about Mailing List Mode, and can apparently still enable the Activity Summary & other emails.
The two admin settings seem to be independent, when perhaps there’s a dependency… does “disallow users from enabling mailing list mode” override “default mailing list mode”?
However, if admin leaves the option “disable mailing list mode” unchecked, the user sees they’ve been defaulted to “Mailing list mode enabled.” This seems clear enough.
Thanks for the update, Sam. I wish I had the chops to develop & offer a PR.
Given the number of fixes and enhancements in release notes, I can only imagine what the backlog looks like. But I do hope this merits attention – users have no reason to suspect that the summary won’t reliably keep them updated.
Hey @ToddZ — my apologies for the radio silence on my end. Thanks for bringing all this up.
I agree with @sam that receiving a notification shouldn’t count as a visit that would prevent you from receiving an activity summary email. I’ll work with the team to fix that and report back once we’ve addressed that issue, though at the moment I don’t have an ETA to share.
