Our Discourse instance is private and we use the discourse-slackdoor plugin to allow Slack to unfurl the contents of posts that are shared in our private Slack.
But Slack still tries to do it’s own unfurling of the links, which is kind of annoying because all it is able to get is the site title and description.
So every link shared in Slack ends up getting the same, additional attachment from Slack that looks kinda like this:
It’s a Slack<->Discourse question. I am guessing others that use Slack and Discourse might have a similar question, so if we come up with a good answer here, it’ll be helpful to this community.
I didn’t realize that was possible. I’ll have to talk to the folks that administer our Slack workspace and point them to this link: Turn off link previews for specific sites
I’m not sure if you’re already aware of this option - apologies if so.
The Slack API has a section on “Slack App Unfurling”. From a brief read it looks like you can do some clever stuff with the API which replaces slack’s default unfurling for specific links with your own logic. Maybe discourse-slackdoor could be adapted to use this method, rather than the existing “sends a message in response” method?
Using this API would also mean users can put the link anywhere in their message, rather than only at the beginning.
The changelog suggests it was added in March, so yeah fairly recent.
In my opinion it would probably be better to keep it separate. The very nature of it (providing a backdoor to a discourse instance) is a potential security risk if not handled correctly, so it’s probably better that it’s only installed on those instances that really need it.
Also I think the slack API scopes required (links:read and links:write) are completely different to that of chat-integration, so there wouldn’t be much effort saved there by combining them.
