Replies: 8 comments 2 replies
-
|
Whatever we wind up with, using a task queue for checking whether to send notifications becomes important because the time it takes to match with all the needed filters will increase. |
Beta Was this translation helpful? Give feedback.
-
|
An audit log is relevant for this... for whodunnit. |
Beta Was this translation helpful? Give feedback.
-
Who gets to set something on planned maintenance?A PM needs an owner and creation date. For starters, must be admin. Set things in maintenance in admin while developing. |
Beta Was this translation helpful? Give feedback.
-
Should it still be possible to to receive notifications (an "ignore planned maintenance"-flag?)Not yet. Only if needed. |
Beta Was this translation helpful? Give feedback.
-
How should planned maintenance be shown in the incident list?Separate column with toggle (show pm, don't show pm, n/a) |
Beta Was this translation helpful? Give feedback.
-
Should it be possible to change PM?Yes. When do we no longer allow changes, if ever?Not 12 hours (setting?) time after "ends". We could make it easy to duplicate a finished pm (same filter, different start/end). |
Beta Was this translation helpful? Give feedback.
-
Should it be possible to abort planned maintenance early?Yes. "Cancel"-button! |
Beta Was this translation helpful? Give feedback.
-
Should there be urls to more information?Yes. None, one, many. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
See #1585 for tracking issue.
"Planned maintenance" is a funded feature.
I think it can work as a much less complicated version of notifications and notification profiles.
PM(owner: User, created: timestamp, starts: timestamp, ends: timestamp, description: text)with one or more filters connected via a many to many relation. If more than one they should be ANDed together like with notification profiles, for higher precision.There should be a single link to a list of planned maintenance items, those that should be done already could be on an "archived" page.
When making a planned maintenance item, for simplicity it should be on it's own page, that'll make it possible to show which existing incidents would be covered as well.
When checking whether we should send notifications, we check the planned maintenance filters first.
Open questions:
who gets to set something on planned maintenance? Should there be a "planned maintainer" user role?
a. just web frontend? then which people?
b. API? then which people? also source systems?
c. admin? then which people?
should it still be possible to to receive notifications (an "ignore planned maintenance"-flag?)
how should planned maintenance be shown in the incident list?
should it be possible to change "starts" and "ends"? if yes, when do we no longer allow changes, if ever?
should it be possible to abort planned maintenance early?
should there be urls to more information?
What is the absolute simplest we can get away with? Then we can add more advanced features later.
Beta Was this translation helpful? Give feedback.
All reactions