# 在 Slack 集成中可选地将帖子线程化到父主题
**URL:** https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759
**Category:** Feature
**Tags:** chat-integration
**Created:** [2020年五月7日 21:33 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759 "2020-05-07T21:33:45Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年五月7日 21:33 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/1 "2020-05-07T21:33:45Z")
在工作中，我们大量使用 Slack。有一些内容需要在 Slack 上可访问，但同时需要良好的组织和搜索功能，而这两点正是 Discourse 的强项。我们尝试过几种类似维基的解决方案，但它们都逐渐被弃用，部分原因是与 Slack 缺乏关联。因此，我正在推动对 Discourse 的评估，使其与现有的 Slack 并行运行并实现连接，因为我已经在运营一个 Discourse 社区论坛了。☺
然而，我们有很多频道都积极使用线程功能。这包括优先级最高的 Slack 频道，需要在 Discourse 和 Slack 之间进行双向（`watch` 和 `post`）集成。
如果让 chat-integrations 插件支持一种 **非默认** 模式：将新主题作为消息发布到 Slack，存储 Slack 消息 ID 与主题的关联，然后将该主题的新评论作为线程消息发送到 Slack，这样是否会破坏该插件的设计？对于我的使用场景来说，这可能是成功与失败的关键区别。
更新：针对我的使用场景，这应该是 `watch` 的一个选项，而不是全站范围的 Slack 聊天配置，因为“偏好使用线程”或“偏好不使用线程”是基于 Slack 频道的目的（以及典型参与者）的每个频道的偏好设置。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020年五月14日 14:33 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/2 "2020-05-14T14:33:36Z")
> [@mcdanlj](#):
>
> 一种模式，将新主题作为消息发布到 Slack，存储 Slack 消息 ID 与主题的关联，然后将该主题上的新评论作为线程消息发送到 Slack？
这听起来是个很棒的主意！将其添加到插件中绝对是 #pr-welcome（欢迎提交拉取请求）
> [@mcdanlj](#):
>
> 双向的
确认一下……你说的“发布”是指现有的转录发布功能吗？还是你想让 Slack 线程与 Discourse 主题“同步”？我认为后者实现起来相当复杂，可能不适合放入 chat-integration 插件中。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年五月14日 17:25 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/4 "2020-05-14T17:25:13Z")
不，我们并不是试图双向同步单个线程，以便你可以在任意一侧发帖并让另一侧同步显示。我曾负责在两个非常活跃的域之间实现完全双向的同步，因此我深知其中容易出错的地方。☺
我们的场景是一个频道，其中：
- 线程化回复是常态，因为该频道往往同时收集多个不相关主题的对话（该频道是面向业务目的而非特定主题设立的；如果不这样做，一个不切实际的替代方案就是每天创建十几个临时频道，并邀请一半的工程人员加入）
- 其中许多（但非全部）线程化对话应被识别为回答了他人的问题，且后续有人希望查阅这些答案。我们会通过集成将这些内容提升为与 Discourse 中相应分类相关的可信内容（例如由我这样的专人主动筛选有价值的回答）
- 在 Discourse 中创建该相关分类下的新主题时，应自动在对应的 Slack 频道中发布帖子
- 这些新主题下的后续评论应以线程形式发布到 Slack，跟随最初的 Slack 帖子
- 我们的用户被引导在 Slack 提问前先搜索 Discourse
此外，你提出这个问题让我想到，作为一个相关功能，如果在将 Slack 线程总结为 Discourse 帖子时，集成能够自动在原始 Slack 线程末尾添加指向新 Discourse 主题的链接，那将非常有用。这将有助于我们将讨论集中在一个地方。
这实际上与最初的功能构想密切相关：如果我们同时具备这两项功能，那么当总结 Slack 线程时，与其发布一条新的 Slack 消息，不如将消息发布到被总结的线程中，并标记该线程为后续 Discourse 评论的发布位置。这样，该线程中的额外 Slack 评论将不会被总结到 Discourse 中，而是旨在将讨论引导至 Discourse 上关于该主题的讨论。这在我看来是合乎逻辑的：
- 前提：存在一个地方可以存储与主题关联的 Slack 消息 ID
- 并且：主题的新评论作为对该存储的 Slack 消息的评论发布
- 结果：在使用 `post thread` Slackbot 集成功能时，将 Slack 消息 ID 与主题关联，从而使该主题上的新 Discourse 评论在该线程中发布通知，并包含指向 Discourse 主题/评论的链接
这将极大地帮助推广“提问前先查看 Discourse”的理念。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020年五月14日 17:34 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/5 "2020-05-14T17:34:02Z")
这听起来都很棒！
> [@mcdanlj](#):
>
> 本意是将该话题的讨论引导至 Discourse。
💯
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [2020年五月15日 04:06 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/6 "2020-05-15T04:06:24Z")
作为视觉辅助，这是否看起来像您想要推广的 Slack 端用户体验？
……哦天哪，线程发起者的年份被省略了。大家猜猜看？
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年五月15日 11:02 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/7 "2020-05-15T11:02:14Z")
@riking 有一点，但存在一些差异。
公告的样式不会完全像那样；它将由集成的 `watch` 端发布。它不会说明帖子已被移动。以下是我目前为 [makerforums](https://forum.makerforums.info) 实现的（非线程化）接口示例，来自 Slack 集成：
在线程化模型中，这些帖子中的第一条会启动一个 Slack 线程，而 Nedman 的评论则会作为该 Slack 线程中的回复出现。当使用 `post thread :thread_url` 时，`:thread_url` 会被存储到新主题中，集成的 `watch` 端会发布初始主题帖子以及后续所有评论到该 Slack 线程，但内容保持不变。
`watch thread` 集成会将你引导至 Discourse，在那里你需要撰写标题，并有机会在发布前编辑新主题帖。因此，发布到 Slack 的公告会先注明运行 `post thread` 的人是作者，然后是一行包含主题标题的链接文本（指向 Discourse），接着是帖子开头的引用摘录。我在此提出的变更是：通过非默认且按频道配置的方式（即 `watch` 选项，而非全站聊天集成插件配置），将该内容发布到线程中，而不是发布到频道中。（不是“也发送到频道”——那将违背我们进行此变更的初衷。）在 Discourse 中对该新主题的任何进一步评论也会进入同一个 Slack 线程。
另外，既然你问到了猜测，那就是 2017 年，Slack 推出线程功能的那一年？
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月9日 20:11 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/8 "2020-06-09T20:11:05Z")
我一直在思考这个问题，并阅读了 [chat.postMessage Slack API 文档](https://api.slack.com/methods/chat.postMessage)，我相信可以将我的一大段文字简化为更简洁的方案。
只有 `watch`（而非 `follow`）具备选择线程回复的能力，其机制我仍在研究中。或者，@david，您觉得是否可以考虑新增一个 `thread` 规则过滤器，优先级顺序为 `mute` \> `thread` \> `watch` \> `follow`，并将该规则通过 `trigger_notification` 传递，以实现基于规则的敏感行为？
1. 如果 `watch` 配置为启用线程（或者定义了 `thread` 规则），在向 Slack 频道发送新帖子通知时，若该帖子主题 **已关联** 一个 Slack `ts`，则通过将 `thread_ts` 设置为从 Slack 提供的 `ts` 值，将消息发布到对应的 Slack 线程中。
2. 在向 Slack 频道发送新帖子通知时，若该帖子主题 **尚未关联** 任何 `ts`，则存储返回响应中的 `ts`（以便后续该主题的帖子在 `watch` 配置为启用线程时能够进行线程化）。
3. 当使用 `post thread :thread_url` 命令时，将线程的 `ts` 存储到所创建的主题中，该值将仅被支持线程的 `watch` 规则使用。
以下是我目前的想法和顾虑：
1. 如何按规则决定是否为线程发帖。目前我觉得新增一个过滤器是最简单的方案，但也许我遗漏了什么。
2. 将原始 Slack 帖子 URL 和线程 ID 贯穿整个转录流程，目前对我来说是最不清晰的部分。这看起来确实需要在某个地方为每个提供商添加一个线程 ID，并一直保留到保存帖子时为止。我目前计划仅针对 Slack 的 `ts` 实现该功能，但预计未来不会只有 Slack 这一种支持线程的聊天集成。
3. 关于发帖，我认为需要在 Topic 上为 Slack 存储一个 Slack 特定的自定义字段（而非通用的 `DiscourseChat` 自定义线程字段）来保存 Slack 的 `ts`。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020年六月10日 12:18 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/9 "2020-06-10T12:18:26Z")
> [@mcdanlj](#):
>
> 如何确定是否按规则发布到线程
‘threading’布尔值真的需要按规则设置吗？为什么不创建一个新站点设置
```plaintext
chat_integration_slack_thread_responses
```
如果启用该设置，并且我们拥有主题的线程 ID 记录，那么后续通知就会发送到 Slack 线程中。
> [@mcdanlj](#):
>
> 关于发布，我认为我需要将 Slack 的 `ts` 存储为 Topic 上特定于 Slack 的自定义字段，而不是通用的 `DiscourseChat` 自定义线程字段。
是的，我觉得这完全没问题。只需使用特定于 Slack 的主题自定义字段即可。如果我们日后觉得有必要为其他提供商实现此功能，可以将解决方案设计得更通用。
> [@mcdanlj](#):
>
> 将原始 Slack 帖子 URL 和线程 ID 传递到转录流程中，这是目前我最困惑的地方
是的，这确实很棘手。作为 v1 版本，我倾向于在帖子顶部包含类似
```plaintext
```
的内容。然后插件可以检查以该字符串开头的帖子，并分配自定义字段。这并不完美，但或许是一个不错的起点？
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月10日 13:08 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/10 "2020-06-10T13:08:31Z")
非常感谢！
昨晚，我实现了前两个 AC（验收标准），并在整个技术栈中通过了所有测试（尽管尚未进行实时测试），但尚未测试转录流程。我使用了 `Topic` 上的一个自定义字段和一个 `thread` 规则。因此，在能够至少在草稿 PR 中展示代码方面，进展顺利。
我还有一个单独的提交，用于移除 Slack 提供者中未使用的 `pstore_get`。既然 `pstore` 在整个技术栈中仅此一处使用，您是否希望我在那个清理提交中也一并移除 `app/initializers/discourse_chat.rb` 中所有的 `pstore_*` 相关代码？
> [@david](#):
>
> “threading”（线程化）布尔值真的需要每个规则单独设置吗？为什么不直接创建一个新的站点设置？
这正是我最初的出发点，那样确实会简单得多！
不过，至少就我的使用场景而言（我也听到其他公司的同事有类似反馈，我们并非特例），不同频道对于是否使用线程有不同的偏好。有些频道设计为使用线程（因为大多数人只关注某些特定话题），而有些频道则强烈反对线程（因为线程会掩盖重要信息）。
我观察到主要有两个本质上不相关的因素在驱动这种偏好：
- 成员构成：大多数成员使用 IRC 数十年的频道，习惯于在单一频道中通过心理区分交织的对话线程，不希望为了查看重要内容而点击进入线程；而大多数成员习惯于电子邮件的频道则期望对话是线程化的，并愿意点击进入他们关心的对话。
- 用途：具有公告业务目的的频道往往积极采用线程化，而用于研究或协作的频道则通常故意不采用线程化，因为线程会隐藏信息，除非用户注意到并点击进入。
如果您希望为规则选项提供某种通用的语法，我认为可以扩展 `Rule`，使其拥有一个 `:options` 值，该值与 `:tags` 类似，也是一个数组。或许可以借鉴命令行 shell 的做法，例如 `/discourse [watch|follow|mute] -something -here` 会将 `:options` 设置为 `['something', 'here']`，即保留前导 `-` 来引入选项。那么命令就可以写成 `/discourse watch my-category-slug #tagged-foo -threaded`。我不确定这比我目前所做的会增加多少工作量。您对此是否有强烈的倾向？我可以看到两种观点的论据：在 Rule 中添加另一个值会使编写聊天提供者变得更加复杂；添加另一个过滤值则会使另一个 Slack 特定功能（如发布转录）变得更加复杂，从而增加非 Slack 用户的使用难度。当然，我可能遗漏了一些会让这比我想象的更困难的细节；例如，如果类别 slug 可以以 `-` 开头，就会导致歧义；shell 使用 `--` 表示“此后的内容都不是参数”，或许我们可以反过来，让 `--` 表示“此后的内容都是选项”。如果您希望我研究这一点，请就规则选项的语法提供指导。不过，对我来说，直接添加 `thread` 似乎更简单，因此，如果没有明确要求添加通用的“选项”功能，我将暂不朝这个方向做任何更改。
[编辑：将规则过滤器改为选项肯定会增加 UI 的复杂性，UI 必须扩展以支持通用的选项功能，这在我看来并不是一个很好的选择。因此，在查看了 UI 之后，我更倾向于坚持使用过滤器；我认为这样更清晰。]
关于帖子转录流程，感谢您提出的 HTML 注释建议。对于我的使用场景来说，这并不会造成任何困扰；说实话，我预计自己至少在初期将是主要用户。这是一个简单而巧妙的技巧。
我还有一个 separate 的想法，不打算包含在这个 PR 中：如果能有一个从消息所属频道到目标 Discourse 帖子所属分类的映射，那就太好了。为了实现这一点，我认为转录最好改为包含一个信封（envelope）或侧车（sidecar），此时信封或侧车可以同时包含类别和 Slack ID。这对我来说似乎需要大量的学习，因为我目前仍处于“通过高级谷歌搜索解决问题”的 Ruby on Rails 学习阶段。😉
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [2020年六月10日 13:35 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/11 "2020-06-10T13:35:34Z")
关于为这个功能锦上添花的另一个想法：
是否可以添加另一个设置项，例如 `cross_post_to_channel_after_hours`（默认值设为 48 小时？），当距离上次回复的时间超过 x 小时，帖子就会被发送到该线程，并附带“同时发送到频道”的标记。
如果您目前只想先让功能正常运行，暂时不必太在意我的建议（这或许是个更好的策略！）。仅供您参考…
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月10日 13:57 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/12 "2020-06-10T13:57:13Z")
这绝不是一个疯狂的想法，但我并不打算实现它，因为这会破坏我的主要使用场景，而且我在其他地方也不需要它。☺ 不过，我完全理解其他人会有这样的需求！
如果这是一个常规设置而不是每个频道独立的选项，那么它应该叫 `chat_integration_slack_copy_threads_to_channel_after_hours`，默认值为 0（不发送），但你可以将其设置为任意值。从概念上讲它相当简单，但需要更多工作，因为你必须获取线程（使用最初为转录功能编写的代码，我不确定是否需要重构），以便决定是否设置一个简单的标志。
但如果你愿意着手实现它，我希望我所做的工作能提供一个良好的框架。我只请求你不要默认开启它，因为如果在升级时默认启用，而我的用户因为我整理内容到 Discourse 而收到“垃圾信息”，那就会引发用户的不满。
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [2020年六月10日 14:33 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/13 "2020-06-10T14:33:30Z")
> [@mcdanlj](#):
>
> 这在概念上相当简单，但需要更多工作，因为你必须去获取该线程
为了简化问题，我认为你可以直接检查 Discourse 主题中上一条帖子的日期。
（在某些情况下它的行为会略有不同，但可以作为不错的起点）
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月11日 00:41 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/14 "2020-06-11T00:41:36Z")
@david 我提交了一个 **草稿** PR，它通过了我编写的单元测试。我还没有尝试在 Slack 上实际运行它，所以在完成之前我不想合并它。但至少所有单元测试都通过了，我也尝试为它们添加了有意义的测试。
我还将 ID 注释放在了帖子的末尾而不是开头，因为我觉得这样更有可能被保留下来，而不会被篡改，并且我尝试在解析时保持谨慎。
感谢你们对这个插件的贡献！
>
>
> In general, this is meant to implement the feature described at https://meta.dis…course.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759 but also includes some cleanups. A few lines of unused or redundant code are cleaned up, and the slack API tests are cleaned up to more accurately reflect the slack API. Requesting a thread does not return arbitrary messages outside the thread; the tests have been modified to more accurately represent this. \`ts\` values are promised to be unique within a channel, so a repetition is changed to follow this contract.
我修复了最初的代码规范检查失败，但现在一些我没有触碰的测试却失败了。我的代码基于最新的 master 分支，本地测试是通过的。你对这些失败的测试有什么见解吗？
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月11日 21:12 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/15 "2020-06-11T21:12:01Z")
我已经对 PR 做了大量清理，但尚未完全准备好。 ~~目前有两三处问题让我感到棘手，我还不清楚如何解决。~~
1. ~~我尝试使用 `fa-arrow-circle-o-right` 作为线程图标，但在我的在线站点 UI 中显示为空。（在检出我的分支后，我会在在线站点上运行 `su discourse -c 'bundle exec rake assets:precompile' && sv restart unicorn` 以在实时服务器上进行测试。）我已在 plugin.rb 中添加了该图标并进行了引用，但接下来该怎么做我有些迷茫。Discourse 是否有一份获准使用的 FontAwesome 图标列表？~~ 我找到了 `lib/svg_sprite/svg_sprite.rb`，其中的 `chevron-right` 非常适合此用途。
2. ~~本地测试全部通过，但在 Travis 中我持续遇到一些看似与我的更改无关的错误，这自然让我难以调查或分析。在 spec/lib/discourse\_chat/provider/slack/slack\_command\_controller\_spec.rb 中有 13 个失败，返回的是 404 而非预期的其他状态码（例如 200）。~~ 通过不再盲目复制 `isolate_namespace` 并学会使用 `rake routes` 已解决此问题。
我已成功发布：
可能还有需要清理的地方，但我觉得这已经可以工作了。
合并之后，我会相应地更新 [https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522/1。](https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522/1%E3%80%82)
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月12日 17:57 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/16 "2020-06-12T17:57:34Z")
我不断在这里发现新的学习机会。现在我知道了如何运行 `yarn prettier`，接下来我要学习如何更新前端测试……
```plaintext
错误：断言失败：您必须使用 set() 来设置 `channel` 属性（对象为 <(unknown):ember3806>）的值为 `<(unknown):ember3799>`。
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020年六月15日 15:57 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/17 "2020-06-15T15:57:19Z")
非常感谢你在这里的所有工作 @mcdanlj —— 现已合并：
>
>
> When creating a new Discourse post from slack with the \`post\` feature, record th…e
> slack \`ts\` thread ID for the resulting topic post using an HTML comment to pass
> the \`ts\` through.
>
> When notifying slack of new Discourse posts, record the slack \`ts\` thread ID in
> the post's topic if it has not yet been recorded. (Normally, this will be done
> for the topic post, except where notifications are being posted for old topics
> before this feature was created.)
>
> Add a new rule filter \`thread\` which posts threaded responses to slack if there
> is a \`ts\` recorded for the post topic.
>
> Modify the \`trigger\_notifications\` interface to enable other integrations to
> implement similar functionality.
>
> Present the \`thread\` rule in the help text and admin UI only for the slack
> providers.
>
> https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年六月15日 16:31 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/18 "2020-06-15T16:31:14Z")
非常感谢你们非常有益的评论！我按承诺更新了官方集成维基帖子。如果你希望用其他方式指出这些变更，我完全没问题，我没有所谓的作者自尊心之类的东西。☺
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [2020年七月6日 19:17 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/19 "2020-07-06T19:17:14Z")
能否在 Slack 的聊天集成设置中启用线程功能，就像
`启用帖子到 Slack 的线程` 一样？
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2020年七月6日 19:52 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/20 "2020-07-06T19:52:16Z")
您的意思是，您希望配置该插件，使其在集成中拒绝响应 `thread` 选项？
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [2020年七月6日 20:25 UTC](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759/21 "2020-07-06T20:25:19Z")
我们几天前已更新至当前的 2.6 beta1a 版本，测试已通过。但据我所知，升级后 Slack 的跨频道帖子仍未形成线程。在 Slack 频道中，主题帖和回复仍以单独的形式显示。
[下一頁](https://meta.discourse.org/t/optionally-threading-posts-to-parent-topic-in-slack-integration/150759.md?page=2)