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

在将 30 个主题从一个分类移动到另一个分类时,我的最有价值的用户收到了大量的电子邮件通知,这让我很头疼。

我注意到在上次更新后,允许在批量选择一组主题并更改其分类时抑制通知的功能的文本已更改。它现在显示如下:

我没有勾选该选项,但它仍然疯狂地给他们发送了邮件!目标分类配置为“Watching first post”(关注首帖),但在这次更改之前,这些通知本应被抑制。

这是怎么回事?

5 个赞

抱歉,@nathank :frowning:

我已尝试在本地重现,并改进了我们的规范覆盖范围以确保我们处理了这种情况…

…但一切似乎都按预期工作 :thinking:

您能提供一些重现步骤吗?

1 个赞

@zogstrip 我没有看到针对这种情况的测试覆盖率。

根据我的理解,describe "silent option" 的规范只涵盖了正在移动的主题已经被“关注”的场景。

这里描述的情况是针对“目标类别”被“关注”或“首次发帖时关注”的场景。

@nathank,据我所知,我们从未静默地做过这件事。

我认为这里发生的情况是,我们确实添加的功能的模态框让它听起来也应该是静默的。我认为我们通过这个模态框改变了期望,而现在我们没有达到这些期望。

这是我的猜测。

我认为这是一个合法的 Feature(功能)或 UX(用户体验)请求,我完全支持这样做。但我不认为它在“技术上”是一个错误或回归。

2 个赞

(作者已删除帖子)

我曾以为这是将此作为批量操作选项的目的之一(以便临时匹配“禁用类别编辑通知”和“禁用标签编辑通知”的行为)。

如果没有它,该功能将受到相当大的限制。

2 个赞

说得好。我老实说不确定。

我确实看到这正是原始功能请求中描述的用例:

我还看到几个人在看到新的复选框时也想到了同样的事情:Bulk editing topic categories should not trigger thousands of email notifications - #12 by mbauman

PR 本身也听起来像是这个意图:

当勾选了“静默执行此操作”复选框时,不应排队等待 :notify_category_change sidekiq 作业。

但我没有看到针对这种情况的明确规范覆盖。

诚然,由于过去几年我没有每天编写代码,我对准备 Ruby 规范有点生疏了,但这确实感觉像是一个可能的差距。

我现在更觉得像是一个错误。不确定是回归还是不是,但确实感觉我们缺少对这种情况的覆盖。

3 个赞

哈哈!我想我发现问题所在了 :bug:

@silent 选项没有正确传播,这导致关注目标分类的用户即使在选中“静默执行此操作”复选框时也会收到通知。

6 个赞

太棒了!感谢您认真对待此事以及如此迅速的修复!我刚刚测试了一下,一切看起来都很好。

我只是想指出,用户界面(UI)中的文本现在不同了/颠倒了——所以勾选复选框所做的与以前完全相反。但那方面似乎工作正常,所以希望一切都好。

以前是:

现在是:

1 个赞

:telephone: 请仔细听,因为我们的菜单选项已更改……

2 个赞