goalert
goalert copied to clipboard
target
Implement API-driven UI For Improved Plug-able Providers
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.
One proposal keeping notification channels and contact methods separate:
notificationChannelTypes: [NotificationChannelTypeInfo!]!
userContactMethodTypes: [UserContactMethodTypeInfo!]!
type NotificationChannelTypeInfo {
id: ID!
name: String!
label: String!
enabled: Boolean!
supportsSearch: Boolean!
}
type UserContactMethodTypeInfo {
id: ID!
name: String!
label: String!
enabled: Boolean!
}
notificationChannelSearch(input: NotificationChannelSearchOptions!): [NotificationChannelInfo!]!
input NotificationChannelSearchOptions {
type: ID!
search: String
}
type NotificationChannelInfo {
id: ID!
type: ID!
name: String!
}
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.