Slack thread_ts support
Closed this issue · 6 comments
Looks that thread_ts parameter get stripped away before send so message does not bind to slack thread.
At originalMessage there is event_ts parameter what looks to be same format than slack api ts. But if I copy it to message.thread_ts it wont do nothing.
Yes the output node cherry picks the right parameters to send to Slack and this is definetely not included, I'll check
Thank you. When you chek look this https://api.slack.com/reference/messaging/payload I think mrkdwn boolean is also good to have
Ok, added it but it seems not to have any effect, slack is supporting markdown by default
Looks that there is new bug.
thread_ts: !_.isEmpty(message.originalMessage.thread_ts) ?
message.originalMessage.thread_ts : undefined
Wont work because that input thread_ts is library own stamp. You need use message.originalMessage.event_ts as source because it contains that original value from slack api. Another hand I am not sure how good idea is set this value by default because it will change default behavior of this library and put all reply messages to thread.
Not sure what's your expected behaviour.
The one I implemented and tested: if a user writes in a thread, the bot answers in the same thread, everything else work as usual (if the use use writes a normal message, then the bot answers with a normal message).
This is working, it's basically copying the thread_ts. I would say 80% of the users will expect that and I think it's fine to have as default.
The use case you're suggesting - correct me if I'm wrong - is to add the option to reply to the user in a thread (of the user's message), in that case the thread_ts would be the event_ts of the user's message.
And yes, this should be optional, for example adding a param in the Param node for Slack like Reply in thread: yes | no
Oh. You are absolute right. I now set to that debug and incoming message wont set bogus message.originalMessage.thread_ts any more. At older lib that message.originalMessage.thread_ts contained some kind timestamp (even when it was not in thread reply) and real thread_ts was in event_ts. But yes it works now as excepted. I had just take away my old workarounds :)