I’ve been thinking about this and reading the chat.postMessage slack API docs, and I believe I can boil down my wall of words to something much simpler.
Only watch
and not follow
has the ability to choose threading responses, by a mechanism I’m still trying to determine. Alternatively, @david what would you think of a new thread
rule filter with precedence mute
thread
watch
follow
, and plumbing the rule through trigger_notification
to enable rule-sensitive behavior?
-
If
watch
is configured to thread (alternatively, athread
rule is defined), sending a new post notification to a slack channel, if the post topic has a slackts
associated with it, post to that slack thread by settingthread_ts
to the providedts
value from Slack. -
When sending a new post notification to a slack channel, and the post topic does not have a
ts
associated with it, store the returned responsets
for the topic (so that future posts on the topic can be threaded ifwatch
is configured for threads). -
When using the
post thread :thread_url
command, store the threadts
in the topic that is created, which will be used only by threadedwatch
rules.
Here are my current thoughts and concerns:
-
How to determine whether to post to threads on a per-rule basis. A new filter feels easiest to me at the moment, but maybe I’m missing something.
-
Flowing the original slack post URL and thread ID through the transcript flow is what is most opaque to me right now. This looks like I really need to add a per-provider thread ID somewhere and preserve it until saving the post. I would implement it only for slack
ts
but presumably it won’t be the only chat integration with threads. -
For posting, I think I need to store the slack
ts
in a slack-specific custom field on Topic, not a generalDiscourseChat
custom thread field.