我网站上有一个话题，是某人（我们暂且称其为X）发布的，后来因为其中包含一些错误信息而被删除了。我将其恢复，并请X在原帖下方发布了更正内容。
从那以后，这个话题不断被删除。我已经将其恢复了两次，看起来一切正常，但过一会儿它又显示为已删除状态。
这是怎么回事？
5 个赞
有没有可能相关用户一直在删除它？我曾遇到过一些用户，他们宁愿删除帖子，也不愿忍受“纠正自己”带来的尴尬。
1 个赞
请查看日志（admin/logs/staff_action_logs），确认是否由用户删除了这些帖子。日志会显示哪些帖子既被编辑过又被删除，以及是由谁删除的。您也可以点击信息图标以获取更多信息。
有些用户后来改变了主意，不再保留帖子，原因有很多。有时，他们只是觉得忘记原本想说的话更好。有时候，即使对方没有给出理由，你也只能接受他们的决定。
4 个赞
不过，用户无法立即删除主题或帖子。他们只能触发一个24小时的待删除流程，这会在主题或帖子中显示为公开的删除意向，如下所示：
（作者已撤回帖子，若未被标记，将在24小时后删除）
此外，只有在主题没有回复且主题发布时间不超过1天的情况下，才能对主题执行此操作。
5 个赞
当主题被系统删除时，我们也会遇到同样的情况：即在作者删除帖子 24 小时后，无法恢复该主题；即使我们将其恢复，它也会在 30 分钟后再次被自动删除。
5 个赞
我已经与用户沟通过，据我了解，他们并非一直在删除它。他们对此实际上感到惊讶，因为正是他们首先向我报告了这个问题。
以下是我的日志显示的内容：
（感谢 @JimPas 的建议！）
有什么想法吗？我还能提供哪些数据来帮助排查问题？看起来 @Pad_Pors 可能遇到过类似的情况。
3 个赞
有人之后找到解决办法了吗？我们也遇到了同样的问题。
一位用户发布了一篇帖子并随后删除了它，请求恢复该帖子，但现在系统不断将其删除（由于这是首篇帖子，整个主题都被删除了）。
我们可以将内容移至新主题，但这样任何访问原始链接的用户都会被带到“页面未找到”的页面。
5 个赞
我们能在周一复现这个问题吗 @tshenry？
5 个赞
你好 @AstonJ
能否确认一下复现步骤？这是我正在测试的内容，但我想确认这是否符合你的预期？
- 用户创建主题
- 用户删除主题
- 主题进入计划删除状态：
- 主题在 24 小时后自动删除
- 用户请求工作人员恢复主题
- 工作人员找到已删除的主题并恢复
- 系统在恢复后再次删除
如果有任何步骤我做得不对，请告诉我。
2 个赞
你好 Taylor，该主题帖是 4 月份发布的，但似乎发生了以下情况：
- 用户点击“提交”创建了主题（因此主题模板被发布——他们表示无法编辑该模板）
- 用户在第二篇帖子中发布内容，然后删除了第一篇帖子
- 第一篇帖子进入计划删除状态
- 用户向工作人员查询此事，担心整个主题帖可能会消失
- 工作人员恢复了第一篇帖子，将第二篇帖子的内容复制进去，然后删除了第二篇帖子
- 主题帖处于活跃状态，包含从 4 月 8 日到 4 月 17 日的帖子
- 系统在此后某个时间删除了该主题帖（不确定具体时间）编辑：其中一位版主指出系统于 7 月 7 日删除了该帖
直到昨天用户发帖询问他们的主题帖在哪里时，我们才发现这个问题。
如果您需要其他信息，请随时告知（顺便一提，这个主题帖一直在被删除）。
4 个赞
嗯。我不太确定第一步中到底发生了什么，但假设结论是用户创建了一个话题，那么第二步似乎是不可能的。如果我以普通用户身份创建一个话题，然后回复它，再尝试删除我的第一条（话题）帖子，第一条帖子不会被标记为删除，这是设计使然。
3 个赞
在我的情况下，流程如下：
- 用户创建主题
- 删除该主题
- 我将其恢复
- 过了一段时间，它再次被删除
我不确定具体的时间范围。
4 个赞
我可以确认，同样的情况在我身上也发生过多次。
2 个赞
据我所知，当帖子被安排删除时，工作人员在普通用户的主题页面上没有可用的“恢复”按钮。只有原发帖者可以在等待期内恢复帖子。当你说“我恢复了它”时，是指自动删除发生之后吗？
1 个赞
啊，对，抱歉泰勒！我猜他们先删了第一个帖子，然后发了第二个——我记得这好像是可行的。
1 个赞
以下是我的解决方案：
- 用户创建主题
- 用户删除主题帖子并安排删除（我将
delete_removed_posts_after站点设置更改为1） - 主题在指定时间后被删除
- 工作人员恢复主题并将帖子还原为原始版本（仅执行“恢复”操作会将帖子带回，并显示“作者已撤回主题，除非被标记，否则将在 1 小时后自动删除”的消息）
- 主题将在一段时间后再次被删除
发生的情况： 当用户删除自己的主题帖子时，会有一个名为 user_deleted 的属性被设置为 true。有一个名为 DestroyOldDeletionStubs 的后台任务每 30 分钟运行一次。该任务会执行 PostDestroyer.destroy_stubs 函数，该函数会搜索数据库并删除所有 user_deleted 为 true 且“删除计时器”已过期的帖子。
问题所在： 当工作人员恢复帖子时，user_deleted 从未被设置为 false，因此下次 DestroyOldDeletionStubs 运行时，该帖子会被再次删除。
解决方案： 我相当确定我们需要在 staff_recovered 函数中添加一些逻辑，将 user_deleted 设置为 false（user_recovered 已经这样做了）。参考：discourse/lib/post_destroyer.rb at main · discourse/discourse · GitHub
快速修复方法： 恢复主题帖子并获取其帖子 ID，然后进入 Rails 控制台并运行：
Post.find_by_id(POST_ID).update(user_deleted: false)
帖子 ID 可以通过在主题 URL 末尾添加 .json 轻松找到。例如，使用此主题：https://meta.discourse.org/t/topic-keeps-getting-deleted/128013.json。该主题帖子的 ID 是 632362。
10 个赞
啊哈，我们应该修复 @eviltrout
出色的侦探工作，@tshenry！
6 个赞
干得漂亮，Taylor 
对于其他需要上述操作的人，请先恢复帖子或主题，否则 find 方法将返回 nil。
4 个赞
我仍然遇到这个问题。关于将 user_deleted 设置为 false 的这项工作有进展吗？
对于托管实例，是否有快速修复方法或变通方案？
2 个赞
我的建议是：
- 将用户设为管理员
- 冒充该用户
- 恢复相关帖子
- 取消该用户的管理员身份
2 个赞