我在想，是否有可能根据标签自动执行主题操作，包括关闭主题。这个问题之前有人问过，但当时 @codinghorror 请求一个用例，却没有人提供——所以我想要提出我们实际遇到的一个用例！
我们有一个面向开源开发者社区的 论坛，此外（与 Discourse 类似），我们还拥有一个托管平台，并提供基础设施相关的客户服务。
经常有人在论坛上发帖，寻求与我们托管服务直接相关的帮助。在这种情况下，我们会使用预设回复关闭该主题，回复中包含联系支持的邮箱地址。这本身并不是问题——但由于主题和预设回复明显是由真人发布的，这会让用户产生负面印象，觉得他们的请求没有得到妥善处理。
有时人们会提到类似这样的话：
“为什么你们团队没时间回复我的邮件，而 [某人] 却有足够的时间来关闭我的论坛主题？？”
当然，实际情况是这两者并非同一团队，我们的论坛也有社区成员协助 Moderation，他们并非我们的员工。但由一个有名字、有头像的人关闭主题，会给人一种印象：似乎是某位员工在 personally 拒绝提供帮助。
我设想的这个用例类似于 GitHub 上的 Bot 工作方式：如果一位 Moderation 人员给某个主题添加标签，然后由一个“机器人”用户自动发布回复并关闭主题。这样，[虽然实际效果并无不同] 或许能减轻人们对正确关闭主题并提供联系方式的 Moderation 人员的抵触情绪。
我对这个想法或解决方案并非特别执着——也欢迎任何关于现有 Discourse 功能或其他处理此类动态的建议 
感谢阅读！
5 个赞
sam
(Sam Saffron)
2
在您的限制范围内，您是否考虑过使用我们的 API 来自动化此操作？
例如，您可以每小时调用一次我们的 API，查找需要关闭的话题（所有带有标签 X 的开放话题），然后使用 API 和一个机器人用户来关闭它们。
您的基础设施中是否有可以调度此类脚本的位置？
2 个赞
我认为那样应该可行——我唯一犹豫的是，该方案在事件发生到处理之间存在长达一小时的延迟，在这个场景下感觉有点久；而且更频繁地调用 API 似乎并不是对资源的有效利用。
有没有一些逻辑上可以接入的节点？
例如，我知道 Discourse 提供 Zapier 集成，但它缺少一个“主题已更新”的事件，而我原本设想可以利用该事件来为此构建一个自定义的自动化方案！
sam
(Sam Saffron)
10
哦……我们实际上在标签上已经有一个 Webhook 了。
你完全可以在此处实现 100% 的响应式处理，而不需要运行周期性任务！
3 个赞
