@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!
