@david - I was trying to post a transcript today and the way the plugin currently handles threads makes it pretty challenging.
It can make it feel like the messages in the transcript are almost completely out of order.
Do you have any insight into how hard it would be to make some improvements in this regard?
Some ideas for options for handling threads would be:
If you post the slash command from within a thread, just grab the whole thread and nothing else
(A) If you post from the main channel, skip messages in the threads
(B) If you post from the main channel, show messages in threads indented underneath the first message
Iâve definitely seen them be disastrous. Until recently, I felt exactly the same way⊠that there was simply no hope (transcripts aside).
But recently, Iâve seen people adopt some patterns that seem to work. There are some channels where now most discussion takes place in threads (the main channel almost looks like a topic list).
So I think there is room for improvement, and Iâm curious whether @david knows any more about what may be technically feasible given his familiarity with the plugin code and the Slack API.
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.
Message sending jobs are queued on sidekiq in the same way as email sending jobs - so as soon as the post is created, a job is scheduled X minutes in the future.
I guess sidekiq doesnât guarantee that scheduled jobs are run in sequenceâŠ
Not really sure what the solution is here - is this a problem solved anywhere else in discourse?
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âŠ
We continue to see adoption in our Slack instance, with many channels explicitly encouraging/demanding that people keep conversations in threads.
Iâm honestly not sure if we would post any more transcripts from Slack if the feature supported it, but there are many cases now where I know we canât really use it as isâŠ
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!
