重复主题标题检查未考虑原始标题是否属于私密分类中的主题，而这一点可能应该被纳入考量。
4 个赞
某个主题是否拥有权限（通过分类）并不影响其是否可能被视为重复的主题标题。
如果是私信，情况则有所不同。
我认为应该如此。这条规则的依据是什么？
本质上就是 Slug 或标题重复。自 2013 年创立以来，这一直是按设计如此。
这就是逻辑，但在我看来，这并非一个站得住脚的理由……我们制定这条规则究竟是想解决或避免什么问题？
既然从 2013 年就是这样，为什么突然成了问题？
我想先看到 3 到 4 份来自客户的问题报告，然后再采取行动。我不会仅凭单一案例就采取行动。
因为对于无法看到其他重复内容的用户来说，这毫无意义。他们被迫编造一个标题，仅仅为了规避某项规则。
我们目前不采取行动也是情有可原，但这仍然需要被记录下来（以防再有 2 个类似情况出现）。
5 个赞
嗯，我认为这在某种程度上是正确的，就像如果密码重复，就不应该允许使用它，即使其他人也使用相同的密码。
http://discourse.example.com/t/upgrading-discourse/8922 和 http://discourse.example.com/t/upgrading-discourse/7451 之间可能产生的混淆是实质性的。
一个涉及安全影响，另一个则纯粹令人困惑……
不过都没关系。我们暂且将此留作记录，目前无需采取任何行动。
2 个赞
唯一真正重要的重复 slug 场景是 SEO。如果一个 slug 位于安全类别中，而我们始终讨论的是安全性较低的议题随后被创建，那么这显然不会成为问题吧？
您好，这里是 Posterity。我们正在创建多个私有分类，每个分类包含相同的主题，但我们遇到了这个问题。请问有什么方法可以绕过吗？
如果您需要此功能，请在站点设置中启用重复标题支持。
4 个赞
请考虑在错误信息中显示冲突的主题 ID。
当主题更新未能通过标题唯一性检查（has_already_been_used）时，错误信息并未指出是哪个主题导致了冲突。这尤其令人头疼，因为该检查是针对 Topic.listable_topics 运行的，所以冲突的主题可能是未公开的（unlisted）。从错误信息到根本原因之间没有直接的路径；工作人员必须知道使用 status:unlisted 进行搜索，并猜测类别或措辞的变化。
对于工作人员/管理员用户，在错误响应中包含该主题的 ID（或管理员 URL）可以将多步调查转变为一步修复，例如：
{“errors”: [“标题已被使用”], “conflicting_topic_id”: 12345}
这是一个相当微妙的平衡，所以我甚至不确定这个更改是否“正确”
我们的想法是，只有在你能够看到另一个主题时，我们才会进行屏蔽。如果你能看到，我们甚至会提供该主题的链接，以便一键查看。
2 个赞
链接是用户端真正需要的最主要内容，所以在我看来这绝对是一个胜利！更不用说，对于如此紧密相关的逻辑，使用单个枚举似乎比使用两个布尔值更好的选择。感谢分享。
1 个赞