Mentions using slack display name format
Closed this issue · 2 comments
Is your feature request related to a problem?
In 0.10.28 it was possible to use the mention_enricher to where the format was User ID, subteam ID or any other string format. The mention_enricher added syntax/format validation in #1286 . This however removed the possibility to do mentions using slack display names like @kristeey and instead enforcing User ID UXXXXXXXX or subteam ID SXXXXXXXX. I do not necessarily disagree on this decision as this removes possibility for "message templating" inside this enricher and enforces a certain standard. However, from a user perspective it is more readable to allow @display.name format. I would like to raise a question why this would/wouldn't be bad practice.
Describe the solution you'd like
Possibility to add a third mentions syntax format for slack display names on the form @.... This will also make it possible to use built in display names such as @here @channel etc.
Describe alternatives you've considered
Alternative is to enforce the strict formatting that is already implemented.
Another alternative would be to open up for any stringformat mention, but this will open the possibility to "misuse" the enricher to use it for message templating.
Would it be satisfactory for you to be able to use the @display.name format just for static_mentions? We could add this back quite easily (unlike the support for this format in labels, that would be more complicated).
Also please note that the use of @display.name has been deprecated by Slack for API clients for quite some time, so we can make no guarantees on how long it will keep working. The official way, unfortunately, is the Uxxxxx format.
This is fair, no worries. I just wanted to hear your opinion. For others reading this: this document could shed some light on the deprecation of slack usernames.
For my use case I would like to utilize the mentions through annotations, because this + annotation based routing gives a lot of flexibility and simplicity when it comes to alerting from clusters where we there are many different users. We will probably solve the manifest generation earlier in our pipeline anyways, so getting User/team IDs for templating can be automated away.