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
watchis configured to thread (alternatively, athreadrule is defined), sending a new post notification to a slack channel, if the post topic has a slacktsassociated with it, post to that slack thread by settingthread_tsto the providedtsvalue from Slack. -
When sending a new post notification to a slack channel, and the post topic does not have a
tsassociated with it, store the returned responsetsfor the topic (so that future posts on the topic can be threaded ifwatchis configured for threads). -
When using the
post thread :thread_urlcommand, store the threadtsin the topic that is created, which will be used only by threadedwatchrules.
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
tsbut presumably it won’t be the only chat integration with threads. -
For posting, I think I need to store the slack
tsin a slack-specific custom field on Topic, not a generalDiscourseChatcustom thread field.