我在 Admin|Emails|Sent 下注意到，摘要邮件没有发送给用户，但他们都收到了 user_watching_first_post 的邮件（根据预设的默认设置）。
我已确认，这些用户并非近期访问过、已过“suppress digest email after days”（几天后禁止发送摘要邮件）设置的时间，或更改了他们的邮件偏好设置。
在这篇旧帖的评论中有人提出，如果发送了其他邮件，摘要邮件就会被禁止：
Need to confirm that digest mails are being sent - support - Discourse Meta
通知邮件是否会被视为用户活动，从而导致摘要邮件被跳过？如果是这样，这并非我所期望的行为……
我们正在为特定标签使用“watching first post”（关注首帖）来通知用户高优先级主题，但我们仍希望他们能收到其他论坛活动的常规摘要。
这对于我们的设想至关重要——我很欢迎任何关于如何实现这一点的建议。
这是正确的。我理解您的担忧，并且过去曾要求对此进行配置。
目前，配置预设监视在一定程度上妨碍了摘要/总结的有效使用。而且这本不必如此。
所以，关于一个主题的电子邮件通知会阻止该主题出现在摘要中，是这样吗？你不想在摘要中收到一封已经通过其他方式发送给你的邮件，这是有道理的。
这远不止于此。收到电子邮件通知似乎会完全重置计数，以至于通知中没有比通知更早的主题会进入摘要。这一直让我很恼火。
基本上，如果收到电子邮件通知的潜在用户不访问网站，那么在前一个摘要和最后一个电子邮件通知之间就不会有任何主题的曝光。而且，当摘要最终发布时，它会让网站看起来比实际情况安静得多。
我希望看到它像您建议的那样，即对于收到电子邮件通知但未访问网站的用户，摘要中只抑制通知的主题。对于那些进行大量默认监视的网站来说，这将是一个巨大的改进！
感谢您的确认，Nathan。是的，尽管有其他符合条件的新主题，但仍未发送摘要。
如果摘要仅避免了重复通知的主题，那是有道理的，但它现在的行为确实看起来像一个疏忽或一个适得其反的错误。
@pfaffman - 听起来像是一个可以被破解的规则吗？或者需要开发人员的关注？
这需要一个插件。我曾经写过一个插件，至少在某个时候声称“在摘要/汇总电子邮件的第三个位置（通常是新用户的位置）添加新帖子的数量。”所以它只改变页面顶部的那个标题。
它会覆盖整个模板，所以这是一个潜在的解决方案。
https://staging.community.pianogroove.com/admin/email/preview-digest
如果你想要这样的东西，可以问我或 Marketplace
仔细考虑后，这确实感觉像是一个 bug，而不是可以通过插件临时解决的问题。我相信这种行为不是故意的。
Site_settings 包含用于禁止摘要的选项，但没有一个与电子邮件通知相关：
更重要的是，用户在 Emails|Activity Summary（电子邮件|活动摘要）中的偏好是：“当我这里不访问时，请给我发送关于热门话题和回复的电子邮件摘要。”——是或否，仅此而已。没有迹象表明与 Tracking emails（跟踪电子邮件）有关。
根据这些设置，用户应该期望 Activity Summary（活动摘要）设置按描述独立应用。
从摘要中禁止通知的主题将是很好的，但我认为那是一种奢侈。仅仅让摘要不了解 Tracking email notifications（跟踪电子邮件通知）就能使其符合预期。
我在这里有点力不从心，但出于好奇，我正在查看 Github 上的代码……
在 app/mailers/user_notifications.rb 的 digest 部分，topics_for_digest 是根据 min_date 查找的，该 min_date 考虑了 user.last_emailed_at
第 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
（编辑：我看到 last_emailed_at 也被引用在 app/jobs/scheduled/enqueue_digest_emails.rb 和 spec/jobs/enqueue_digest_emails_spec.rb 等地方。）
这让我认为，对于 user.last_emailed_at 太近的用户，根本不会生成 digest。
我无法分辨哪些电子邮件计入 last_emailed_at。显然，它包括基于跟踪设置的通知，但私人消息等呢……？
摘要不应该只关心 user.last_seen_at 吗？
是的，鉴于我们所说的，这感觉像是一个错误：
我想知道最终用户在这里应该有多少保真度：
给我发送摘要：无条件 | 当我不在时 | 只要这是我本月收到的唯一一封来自您的电子邮件
边缘情况似乎是故意的，并且必须与那些将 Discourse 用作邮件列表的人有关。
我认为我们首先需要仔细定义这里的特性，我将将其移至特性并加上成员体验标签。
谢谢，Sam！
目前，当启用邮件列表模式时——至少在用户偏好设置级别（请参阅下一篇文章）——界面会清楚地表明摘要设置已被覆盖。
所以也许唯一需要添加的是“始终发送”，例如：
活动摘要：
始终向我发送电子邮件摘要
仅在我未访问此处时向我发送电子邮件摘要
（下拉菜单）：每 30 分钟 | 每小时 | 每天 | 每周 | 每月 | 每六个月
但我认为“始终发送”选项是锦上添花。仅仅让摘要独立于其他电子邮件似乎就能使其按预期工作。
（题外话：如果我有一个大型论坛，我可能会希望管理员可以配置可用时间范围。太多人选择“始终发送……每 30 分钟”可能会增加电子邮件费用。）
这与我报告的问题是次要的，但与 Sam 对邮件列表模式与活动摘要的担忧有关……
有趣的是，当管理员启用“默认邮件列表模式”和“禁用邮件列表模式”（场景 A）时，不清楚会发生什么。用户看不到任何关于邮件列表模式的信息，并且显然仍然可以启用活动摘要和其他电子邮件。
这两个管理员设置似乎是独立的，但也许存在依赖关系……“不允许用户启用邮件列表模式”是否会覆盖“默认邮件列表模式”？
管理员设置，“邮件列表”：
用户偏好|电子邮件：
但是，如果管理员不选中“禁用邮件列表模式”选项，用户会看到他们已被默认设置为“已启用邮件列表模式”。这似乎足够清楚了。
管理员设置，“邮件列表”：
用户偏好|电子邮件：
因此，场景 A 中似乎缺少一些东西，以表明邮件列表模式是否真的处于活动状态。（除非是我错过了。）
您好，会员体验团队——我想知道，这件事是否已进入队列以供进一步关注？
只是想回访一下，看看这件事是否在考虑之中……
我已经向 @lindsey 反映了这个问题，但遗憾的是她还没有找到时间将其纳入任何路线图。
我认为我们目前正处于 pr-welcome 的世界，即先尝试一下，然后我们可以审查是否将其纳入。
感谢你的更新，Sam。我希望我能有能力去开发并提交一个 PR。
鉴于发行说明中有大量的修复和增强功能，我只能想象积压的工作量有多大。但我确实希望这能引起重视——用户没有任何理由怀疑摘要不会可靠地让他们了解最新情况。
嘿 @ToddZ — 很抱歉我这边一直没有回复。感谢你提出所有这些问题。
我同意 @sam 的观点，收到通知不应被视为一次访问，以免你收不到活动摘要电子邮件。我会与团队合作解决这个问题，并在我们解决该问题后向你汇报，不过目前我还没有可以分享的预计完成时间。
谢谢你，@lindsey！我知道预估时间很难——很高兴知道它正在进行中，并期待更新。
感谢 @ToddZ 的报告 
此问题将通过以下方式修复：
此主题在 44 小时后自动关闭。不再允许回复。
