Activity Summary not sent if other emails are sent

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.

It’s suggested in comments on this older post that digests are suppressed if any other email is sent:
Need to confirm that digest mails are being sent - support - Discourse Meta

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.


That is correct. I share your concerns, and have requested that this was made configurable in the past.

At present, configuring preset watching somewhat hampers the effective use of the digest / summary. And it needn’t.

1 Like

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.

If you want something like that you can ask me or marketplace

1 Like

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 =
          .for_digest(user, min_date, digest_opts.merge(include_tl0: true))
          .where("topics.created_at < ?", 24.hours.ago)

(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 ?


Yes, this feels like I bug given what we have written on the tin:

I wonder how much fidelity end users should have here:

Emails me digests: Unconditionally | When I am not around | As long as its the only Email I get from you this month

The edge case feels deliberate and must relate to people using Discourse as a mailing list

I think we need to carefully define the feature here first, going to move to feature and put member-experience on it.


Thanks, Sam!

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”?

Scenario A

Admin settings, “mailing list”:

User preferences|Emails:

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.

Scenario B

Admin settings, “mailing list”:

User preferences|Emails:

So something seems to be missing in Scenario A that would indicate whether Mailing List Mode is really active. (Unless I’m missing it.)

Hi, Member Experience team – just wondering, has this made it into the queue for further attention?

Just checking back to see if this is on the radar…

I raised this with @lindsey already but sadly she has not found the time to fit it into any roadmap yet.

I think we are sitting at the moment in the pr-welcome world of give it a shot and then we can review for inclusion.

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.


Thanks, @lindsey! I know ETAs are tough – I’m glad to know it’s in the works, and will look forward to updates. :smiley:

1 Like

Thanks @ToddZ for the report :+1:

This will be fixed by


This topic was automatically closed after 44 hours. New replies are no longer allowed.