Continuation of https://github.com/discourse/discourse-slack-official
Take a snapshot of a discussion in Slack and post it as a topic in Discourse. The output should be a cleanly formatted chat transcript. The average snapshot would be between 5-100 messages long. Also see “Wisemonk - a Slack bot to move discussions from Slack to Discourse”.
Use Discourse as your “long term memory” for Slack conversations worth remembering.
- Type a command like
/topic last:50 category:staff in Slack.
@system (or other designated user) create a new topic in the #staff category. This topic will contain your 50 last Slack messages (in plaintext or minimal Markdown).
- Set custom timegap for the snapshot:
from:15:35-16:10 (might be tricky due to timezone differences)
- Ignore messages from selected users in snapshot:
- Post as the user who issues the command via Slack
- Open pre-filled topic in browser instead of posting directly
- A graphical interface for posting snapshots. Might be possible to do something using Slack Buttons.
What about a “pull” approach instead of “push”?
- Copy link to particular slack message
- Paste it into discourse
- Onebox has settings for authentication with private slack instances to feature message
- Onebox appends something like [before:0,after:0] to the end of the link, indicating that it’s going to suck in 0 messages before and after the link (maybe site settings to control those defaults?)
- User can edit the plaintext to add more messages before and after the post
I think this would be easier to reason about, and allow pasting slack messages as a new topic or inside any post…
I’m calling it “Onebox” above, but maybe its more of a hybrid onebox/plugin thing… not sure the implementation, just using it as a shorthand for the UX.
Certainly worth considering. @vinothkannans is gonna be working on this, so if our initial plan fails, he can try the “pull approach” instead.
Just a quick thought on this - it’s quite a security risk to add oneboxing capability to slack messages… The links to messages on slack are essentially
so not exactly hard for someone to guess. Then if they wanted to read your private Slack messages they could make requests to something like
Not necessarily a deal-breaker depending on the organisation, but something to bear in mind if someone does implement this “pull approach”. Should be reasonably safe in a
login_required discourse instance.