You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What problem would you like to solve? Please describe:
As part of the ongoing efforts noted in issue #2639 to implement plugins/plug-able providers for notifications, we aim to continue this overhaul by making the UI elements like contact methods, escalation policy step assignments, and schedule notifications API-driven rather than hardcoded.
This aims to ease maintenance on current providers, and more importantly, is the core requirement for allowing plugins, where the provider types/names/etc won't be known until runtime.
Describe the solution you'd like:
We require the addition of new queries for the different types that will be used in form building (e.g., the contact method form, or the escalation policy step dialog), a generic query for searching (e.g., for things like Slack channels), and corresponding updates to the UI to make use of these API-driven elements.
This follows a similar approach we've successfully implemented by introducing an integrationKeyTypes query.
Describe alternatives you've considered:
Currently, no other alternatives have been considered due to the necessity of API-driven UI for implementing plugins.
Additional context:
This is continuation of previous efforts noted in issue #2639, aiming to implement plug-able providers.
The text was updated successfully, but these errors were encountered:
We will likely keep Slack user groups out-of-scope for this, as it's more of an automation with error reporting than a notification destination; that type of thing doesn't fit well with any of the other delivery methods and should have its own criteria.
What problem would you like to solve? Please describe:
As part of the ongoing efforts noted in issue #2639 to implement plugins/plug-able providers for notifications, we aim to continue this overhaul by making the UI elements like contact methods, escalation policy step assignments, and schedule notifications API-driven rather than hardcoded.
This aims to ease maintenance on current providers, and more importantly, is the core requirement for allowing plugins, where the provider types/names/etc won't be known until runtime.
Describe the solution you'd like:
We require the addition of new queries for the different types that will be used in form building (e.g., the contact method form, or the escalation policy step dialog), a generic query for searching (e.g., for things like Slack channels), and corresponding updates to the UI to make use of these API-driven elements.
This follows a similar approach we've successfully implemented by introducing an
integrationKeyTypes
query.Describe alternatives you've considered:
Currently, no other alternatives have been considered due to the necessity of API-driven UI for implementing plugins.
Additional context:
This is continuation of previous efforts noted in issue #2639, aiming to implement plug-able providers.
The text was updated successfully, but these errors were encountered: