opensearch-project
[FEATURE] Add support for Mattermost channel as destination
Is your feature request related to a problem?
Up until OpenSearch v3, we were using Slack destination type with the Mattermost channel webhooks and that was working fine, as the message has the same format, i.e., {"text": "my-message"}. However, after a url validation got in-place (https://github.com/opensearch-project/notifications/pull/814) this no longer works.
What solution would you like?
Since it was decided that the Slack destination type should follow its own lonely path, there needs to be a solution for other type of tools that use {"text": "my-message"} format.
I list below some possible solutions, but feel free to counter-suggest others:
- Create a dedicated Mattermost channel destination type, similar to the Slack one, but with a different webhook url validation (
Regex("https://.*/hooks/.*")instead ofRegex("https://hooks\\.(?:gov-)?slack\\.com/services"))). - Extend the custom webhook destination type to support either any format, or at least the
{"text": "my-message"}one. This way, all previously "Slack" destinations that are not really slack, can be converted into Custom webhooks and still keep the same custom message format, instead of the default. So do not just return message.textDescription. Essentially, as suggested here: https://github.com/opensearch-project/notifications/issues/818 - Revert https://github.com/opensearch-project/notifications/pull/814 and optionally then generalise the "slack" destination name, as this destination type can be used for multiple tools (not just slack).
What alternatives have you considered?
We can always wrap Alert monitors text with {"text": "my-alert-message"} format. It works, but that is not elegant.
Given how many platforms support the Slack incoming webhook format (Slack, Discord, RocketChat, Zulip, Mattermost...), it might be worth reconsidering the need to validate the destination URL. Since the format is widely adopted across different services, enforcing strict URL validation could unnecessarily limit flexibility for users who want to integrate with alternative platforms 😢
