#1098 is about adding basic support for attribute negotiation. There is a sane default for relation attributes suggested, that is included when transmitting events to Icinga Notifications. This is about that users of Icinga Notifications Web will be able to customize this default in the UI, in order to reduce the overhead the negotation potentially introduces.
This requires a new database table (icingadb_config) where configuration options can be stored. For simplicity reasons and given that a similar approach is already in place for environment variable configuration, I suggest a key-value table where keys are e.g. underscore-separated option names (e.g. LOGGING_LEVEL, just to mention a familiar option) and the value what generally is expected in these circumstances.
For the option described here, I'd go with NOTIFICATIONS_DEFAULT_RELATIONS for example and a list of JSONPath components, as they're usually used by Icinga Notifications to signal what's missing.
#1098 is about adding basic support for attribute negotiation. There is a sane default for relation attributes suggested, that is included when transmitting events to Icinga Notifications. This is about that users of Icinga Notifications Web will be able to customize this default in the UI, in order to reduce the overhead the negotation potentially introduces.
This requires a new database table (
icingadb_config) where configuration options can be stored. For simplicity reasons and given that a similar approach is already in place for environment variable configuration, I suggest a key-value table where keys are e.g. underscore-separated option names (e.g.LOGGING_LEVEL, just to mention a familiar option) and the value what generally is expected in these circumstances.For the option described here, I'd go with
NOTIFICATIONS_DEFAULT_RELATIONSfor example and a list of JSONPath components, as they're usually used by Icinga Notifications to signal what's missing.