# 尝试静默移动 Topics 到不同分类时意外的邮件/通知泛滥

**URL:** <https://meta.discourse.org/t/inadvertent-flood-of-emails-notifications-when-attempting-to-silently-move-topics-between-categories/390993>\
**Category:** Bug\
**Tags:** email, bulk-actions\
**Created:** [2025年十二月10日 22:51 UTC](https://meta.discourse.org/t/inadvertent-flood-of-emails-notifications-when-attempting-to-silently-move-topics-between-categories/390993 "2025-12-10T22:51:22Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![mcwumbly](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcwumbly/32/103861_2.png) [@mcwumbly](https://meta.discourse.org/u/mcwumbly)\
**Post date:** [2025年十二月11日 11:02 UTC](https://meta.discourse.org/t/inadvertent-flood-of-emails-notifications-when-attempting-to-silently-move-topics-between-categories/390993/3 "2025-12-11T11:02:16Z")

</div>

@zogstrip 我没有看到对此情况的测试覆盖。

根据我的理解，`describe "silent option"` 的测试用例仅覆盖了主题已被关注的场景。

这里描述的情况是目标分类处于“已关注”或“关注首帖”状态的场景。

@nathank，据我所知，我们从未静默处理过这种情况。

我认为，问题可能在于我们添加的功能的模态框让用户误以为这也应该被静默处理。这个模态框改变了用户的预期，而我们现在没有满足这些预期。

这只是我的猜测。

我认为这是一个合理的 #Contribute > Feature 或 #Contribute > UX 需求，我完全支持实现它。但我认为这 _技术上_ 并不是一个 bug 或回归问题。

---

_[View the full topic](https://meta.discourse.org/t/inadvertent-flood-of-emails-notifications-when-attempting-to-silently-move-topics-between-categories/390993)._
