Notifications should also be sent to contacts, if they happen outside an incident and don't trigger one themselves. With regard to Icinga DB, these may be downtime start or flapping notifications.
UI
The current event rules will need to be re-labelled as escalation rules. The new rules are labelled notification rules. Both are configurable in the same unified view and the user needs to decide which to set up upon creation.
- The current configuration section Event Rules will be re-labelled as Rules
- The modal currently used to create an event rule will show an additional radio input, similar to how a schedule rotation's mode is chosen
Notification rules do not have any escalations and as such no conditions and differ otherwise only in what is configurable as filter. Escalation rules don't change due to this.
The basic UI should be the same regardless of the type, so the source and filter are displayed and configurable the same way.
The difference with the filter is that while escalation rules only allow to target objects, notification rules allow to target both objects and events. The column suggestions and validation must be adjusted for this, so that integrations know what the user is going to configure.
In contrast to escalation rules, the remaining part of the UI directly leads to a single set of recipients. The recipients themselves are configurable the same way, though.
@flourish86 will provide mockups visualizing this general idea.
Implementation
As I suggested to just add a type enum column to table rule in Icinga/icinga-notifications#409, EventRuleConfigForm should support both types and switch according to that column.
Since filters are gonna be configured differently anyway with #450, there should already be a new hook available which can be extended to also request an editor for notification rules from an integration.
Notifications should also be sent to contacts, if they happen outside an incident and don't trigger one themselves. With regard to Icinga DB, these may be downtime start or flapping notifications.
UI
The current event rules will need to be re-labelled as escalation rules. The new rules are labelled notification rules. Both are configurable in the same unified view and the user needs to decide which to set up upon creation.
Notification rules do not have any escalations and as such no conditions and differ otherwise only in what is configurable as filter. Escalation rules don't change due to this.
The basic UI should be the same regardless of the type, so the source and filter are displayed and configurable the same way.
The difference with the filter is that while escalation rules only allow to target objects, notification rules allow to target both objects and events. The column suggestions and validation must be adjusted for this, so that integrations know what the user is going to configure.
In contrast to escalation rules, the remaining part of the UI directly leads to a single set of recipients. The recipients themselves are configurable the same way, though.
@flourish86 will provide mockups visualizing this general idea.
Implementation
As I suggested to just add a
type enumcolumn to tablerulein Icinga/icinga-notifications#409,EventRuleConfigFormshould support both types and switch according to that column.Since filters are gonna be configured differently anyway with #450, there should already be a new hook available which can be extended to also request an editor for notification rules from an integration.