#5402 closed defect (bug) (fixed)
Can @group be sanitized on the Trac>Slack integration to avoid the flag
Reported by: | garrett-eclipse | Owned by: | dd32 |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Trac | Keywords: | |
Cc: |
Description
Hello,
Can the content posted from core Trac to Slack sanitize the @group
as it currently will flag in the #core-firehose for example;
https://core.trac.wordpress.org/ticket/51184#comment:15
https://core.trac.wordpress.org/ticket/50910#comment:20
https://core.trac.wordpress.org/ticket/46431#comment:4
Screenshot coming.
Thanks
Attachments (2)
Change History (10)
#1
@
4 years ago
Last time I looked into this, I was told that while it looks like it's a ping, it shouldn't actually be a ping.. I don't believe that's quite true though..
In testing, putting it inside a code tag should prevent it being a ping, but it looks like in these cases that's not helping.
Any suggestions on how we can escape it/etc that makes sense?
For what it's worth, we use Incoming webhooks for sending messages to Slack: https://meta.trac.wordpress.org/browser/sites/trunk/common/includes/slack/send.php
#2
@
4 years ago
Ah, found it. Slack Formatting specifies that bots can't use @(channel|here|group)
directly and should use <!(channel|here|group)>
instead.. however.. Slack also has some auto-parsing which will convert it on the fly - I don't think that was always there. Since we set the link_names
parameter to true, that gets triggered.
#3
@
4 years ago
Thanks for looking into this @dd32 it sounds like you've found the culprit. Reading into it sounds like we can omit the link_names
param and disable the auto parsing as it only works on conversations and user groups which I don't think are desired;
We've already deprecated this functionality for user mentions, so always parsing manually will keep you prepared in case automatic parsing is deprecated for other entities like conversations or user groups in the future.
Deprecated link - https://api.slack.com/changelog/2017-09-the-one-about-usernames
They also mention manual parsing is preferred if they decide to deprecate other autoparsing features.
#4
@
4 years ago
- Owner set to dd32
- Resolution set to fixed
- Status changed from new to closed
In 10264:
#5
@
4 years ago
Let's see if that worked... @group this is a test message :)
Looks good to me: https://wordpress.slack.com/archives/C03BD0WG1/p1600230488023600
#7
@
4 years ago
@dd32 I think we should keep this enabled for the /here broadcasts because now the channel name is no longer linked.
Example: https://wordpress.slack.com/archives/C02RQBWTW/p1600279125290500
@group instances of late that have flagged and can be seen highlighted in search.