Currently, non-administrative users can send notifications to Seq Apps (e.g. the Slack or Email notifiers), but only administrators can stream events to an app.
This makes some integration and alerting scenarios awkward - for example, a user may wish to receive the full payloads of error events via email, or, record some stream of useful information to an external tool for analysis.
We've historically steered away from allowing non-administrative users to configure apps at all, but in Seq 4.2 we introduced the concept of overridable settings on app instances. This enables the currently-supported notification system by limiting the settings that non-admins can configure to a predetermined set.
If we were to allow non admins to create personal "outputs" that effectively behaved like app instances, but only using pre-installed apps and whitelisted properties, these could fill this feature gap.
It's also possible that the concept of an "output" might be useful for administrative users, too, since it would separate the configuration of mundane "global" properties (such as SMTP server details) associated with app instances, from the use-case-specific properties (such as "Subject" or "To" or "Channel") associated with individual outputs.
Currently, non-administrative users can send notifications to Seq Apps (e.g. the Slack or Email notifiers), but only administrators can stream events to an app.
This makes some integration and alerting scenarios awkward - for example, a user may wish to receive the full payloads of error events via email, or, record some stream of useful information to an external tool for analysis.
We've historically steered away from allowing non-administrative users to configure apps at all, but in Seq 4.2 we introduced the concept of overridable settings on app instances. This enables the currently-supported notification system by limiting the settings that non-admins can configure to a predetermined set.
If we were to allow non admins to create personal "outputs" that effectively behaved like app instances, but only using pre-installed apps and whitelisted properties, these could fill this feature gap.
It's also possible that the concept of an "output" might be useful for administrative users, too, since it would separate the configuration of mundane "global" properties (such as SMTP server details) associated with app instances, from the use-case-specific properties (such as "Subject" or "To" or "Channel") associated with individual outputs.