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
Currently it is possible to select which users to notify by e-mail when a job completes, by entering a list of e-mail addresses. It would be better though if users could subscribe to job results. This would allow users to monitor a configuration that they're not the owner of.
There could be a notifications management page for each user, where they can see which configurations they're subscribed to and be able to unsubscribe with a single button instead of having to edit the configuration.
There could also be subscription types other than e-mail. For example, a user could subscribe to configurations they want on a dashboard or custom Atom feed.
One thing that would be a little harder compared to the current approach is subscribing a non-personal e-mail address to configurations. However, that is still possible by creating a functional guest account to manage the subscriptions, so this is only a mild inconvenience.
The text was updated successfully, but these errors were encountered:
I created issues in the GitHub tracker for the ideas in this document
that were still relevant: #9#10#11#12#13#14#15#16#17#18#19#20
We want to create a new roadmap at some point, containing visions for
the future rather than concrete feature plans. But when we do that,
it should not be part of the installed documentation, but kept on
for example a web site or wiki instead.
Perhaps a configuration is not the ideal entity to subscribe to, since they can be used for both scheduled and ad-hoc executions. Subscribing to a schedule or a specific job might make more sense.
Currently it is possible to select which users to notify by e-mail when a job completes, by entering a list of e-mail addresses. It would be better though if users could subscribe to job results. This would allow users to monitor a configuration that they're not the owner of.
There could be a notifications management page for each user, where they can see which configurations they're subscribed to and be able to unsubscribe with a single button instead of having to edit the configuration.
There could also be subscription types other than e-mail. For example, a user could subscribe to configurations they want on a dashboard or custom Atom feed.
One thing that would be a little harder compared to the current approach is subscribing a non-personal e-mail address to configurations. However, that is still possible by creating a functional guest account to manage the subscriptions, so this is only a mild inconvenience.
The text was updated successfully, but these errors were encountered: