I had a look at the API. It looks like we can’t specifically request messages that are/aren’t part of a thread. As you have noticed, messages are simply loaded in chronological order regardless of what thread they’re in. This can lead to a lot of mess!
When we retrieve messages, we are told whether they are part of a thread. So that means it’s definitely possible to filter them out on the discourse end, meaning that the transcript would only contain messages that are part of the “main” conversation. We would need to be careful to include those messages that are “broadcast” out of a thread into the main channel.
As for posting a transcript of a thread - as far as I can see, custom slash commands aren’t supported in threads… So that’s not a great start! This is the only mention of the issue I can find.
So to go back to your list:
I don’t think this is possible, because slash commands don’t work in threads
I think we can do this fairly easily
This would be cool. How long do your threads tend to last? If the first post of a thread is more than 500 messages in the past then we might have an issue… And that 500 includes all posts in all threads that are part of a channel.
Tl;dr: Threads in Slack seem like a bit of an afterthought as far as the API is concerned!
Hmm… Sounds like it. thanks so much for the thorough notes on what you’ve found.
I haven’t seen many threads with more than 20 messages, so I think this would work out pretty well.
The bigger issue I see is actually something like this:
user posts message
others respond as a thread
many more messages in main channel
another response in thread from (1).
If there’s a lot of message in between in step (3), than the message in the thread from step (4) might get missed. (Or another way to put it is that I’ll have to include a bunch of junk from (3) that I might not care about just to get the message from (4).
That’s a bummer. As you said, seems like their API could use some love. But I think this option (B) would come the closest to behaving in an “expected” way for people that use threads.
So I think that means, given the start message, we can load its replies. It will require an HTTP request for every individual thread, which isn’t great, but since we are deferring the transcript processing anyway it might be ok.
Implementing that is achievable, but will be a fairly large amount of work.
In the meantime, here is a PR ignores any “thread replies” in a transcript. So given a slack channel like this:
Something I’ve noticed every so often is that Slack messages come in out of order. This occurs when multiple posts happen near the same time on Discourse, they sometimes are posted to slack in a different order. This can be confusing if both posts were from the same topic - the reply is posted in Slack above the post that was replied to.
Just bumping this again since I used the transcript feature today. It was very helpful, but I did have to go in and manually insert some of the threaded messages myself. Thread adoption is real at our place, so still would love to see this at some point…
Unfortunately Slack still don’t support custom slash commands in threads, so we’re stuck with performing the slash commands in the context of the main channel
The main problem we have with implementing thread support with a UI is obtaining human-readable names for each of the threads in the channel. If the thread starts more than 500 messages in the past, there is no way to get a sensible name without an additional HTTP request.
Judging by their API page, it looks like Slack have started implementing fairly strict rate limits for third parties. If we’re making many HTTP requests to fetch thread titles, then we’re going to hit the 50 req/min limit pretty quickly.
However, we could do something like this pretty easily:
/discourse post thread https://<slackname>.slack.com/archives/C6029G78F/p1522952993000017
(the URL is the slack thread URL)
We could skip the ‘start/end message’ UI, and just put the whole thread in the transcript.
The obvious problem is that it’s quite ninja, and not particularly pretty. What do you think @mcwumbly, do you think it would still be useful?
Can we stop blocking the word thr3ad yet? I just had to edit 8 legitimate occurrences in this post!
I think one option we would be open to is a pr that allows you to set which TL has particular blocked words, cause blocking thread from tl0 and 1 is pretty much our intent here, plus we want to make the feature better, and there are tons of missing refinements here that are missing, like teaching people why a word is blocked (optionally) vs just saying sorry, not allowed
Hey @david - Just got a chance to try out the new feature to post threads… looks like it’s not quite working or us.
I tried each syntax or a couple different threads, but just get this in response:
Loading the transcript…
Using the normal command continues to work as it did before, though.
Also, when I tried posting a transcript from a private channel, I got this:
Darn - that slash command didn’t work (error message: 422_client_error). Manage the command at Discourse
I looked at the diff from the PR and thought perhaps it’d be necessary to add the conversations:history scope to the app on Slack, but I didn’t see that as an option. I tried adding the groups:history scope instead, but that did not seem to work.
Let me know if there’s anything else you’d like me to try for either of these issues. Thanks!