REST API 编辑中对 bypass_bump 的赞赏

开发
1

继续讨论 如何使用 API 编辑帖子而不顶起话题？：

我想再次对 Discourse 团队包含 bypass_bump 参数表示衷心感谢！它是一个小巧但功能强大的工具——它允许脚本和插件在后台更新内容，而不会无意中将旧话题显示在最新视图中。

在我们的案例中，我们将其用于 ICS 同步脚本，它确保只有有意义的更改才会顶起话题。这是一个周到的补充，它使社区论坛保持整洁，并且不会干扰读者的体验——再次感谢！

2 个赞
2

这不是一个误导性的赞扬帖，不像我上一个帖子🙈，因为：

  • Discourse 在修订帖子时支持 bypass_bump 标志；即使您编辑了最后一个（或第一个/唯一一个）帖子，它也会阻止主题的“bump”日期发生变化。这在 PostRevisor 选项中明确列出（“- bypass_bump：即使是最后一个帖子，也不要“bump”主题”）。
  • 这个赞扬主题存在，并且准确地说明了该用例。
  • 过去人们使用 /t/{id}/reset-bump-date 的变通方法，因为这个选项在 API 文档中并不广为人知/未被记录，但如果需要，它仍然可用。

实际注意事项：当您使用新的 raw 内容 PUT /posts/{post_id}.json 并包含 bypass_bump=true 时，编辑将不会在 /latest 中显示该主题。（官方文档没有详细说明此参数，但它通过 PostRevisor 在服务器端进行了连接。）

3

我仍然不完全确定 bypass_bump 在 API 文档中的官方状态——它没有出现在任何显眼的位置。

但当我查看 Ethsim12 的 Python 同步脚本的日志时，它们很有启发性。该脚本尝试使用 bypass_bump=true 调用 API。如果该参数被忽略或无效，唯一能阻止不必要 bump 的就是他们添加的回退：手动调用

/t/{topic_id}/reset-bump-date

因此，日志输出本身就成为有力的证据。如果日志显示主题被更新但未出现在 /latest 中（并且不需要重置回退），那么这足以证明 bypass_bump 存在且正在运行。如果日志总是回退到 reset-bump-date，那么它可能不存在。

换句话说：此脚本的日志在很大程度上证实了 bypass_bump 是否存在以及服务器是否实际尊重它。

4

您可能对这个拉取请求感兴趣

2 个赞
5

感谢分享这个 PR，moin——提供了非常有用的背景信息。

对于我的个人项目（ics_to_discourse.py 导入器），我实际上刚刚提交了一个更改，以停止由日历驱动的更新“嘈杂地”顶帖：

该提交添加了一些逻辑来判断编辑是否“有意义”（例如时间/地点更改等），并使用 bypass_bump 加上一个重置 bump-date 的回退机制，以便常规的 ICS 同步不会不必要地显示帖子。

因此，这个 PR 与我的目标完全一致——很高兴看到核心也在朝着同一个方向发展。一旦“编辑时不顶帖”的行为被合并，我将简化并删除额外的回退机制，但目前该提交可以保持当前 Discourse 安装的安静。

6

我刚刚在 Praise 中注意到这一点，并已将其移至 Dev，因为它相当技术性。当然，我很感激赞美！:hugs:

1 个赞
7

嗯，我重新阅读了此主题，并意识到我没有包含另一个相关的 PR，当时我不在大学，有时间编写代码