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
Changing the start_time of an incident does not update the mtime of the first incident, so the statusboard on /home/ does not show the updated times. The first status mtime should be updated to match.
A problem will occur if the time is brought forward past the creation of a status change so as to orphan a status change before the incident was even created.
The text was updated successfully, but these errors were encountered:
Commit f399406 partially fixes this issue. When the incident start_time is changed, the ctime of the initial status is also updated so as to display correctly throughout the application. Subsequent status changes are not amended.
This feature is useful in the case where planned future maintenance is rearranged, but can be misused to change past incidents as well.
Reasonable options are:
Accept that users shouldn't be changing the timestamp of something that's already happened and ignore the breakage. it doesn't mess up the webui, but does look odd in the status history for the incident.
Prevent start_time changes if that time has already elapsed
Force the timestamps for all subsequent status changes to be amended when changing the incident start time (additional UI required)
Delete all status changes with a time before the new incident start time
Changing the start_time of an incident does not update the mtime of the first incident, so the statusboard on /home/ does not show the updated times. The first status mtime should be updated to match.
A problem will occur if the time is brought forward past the creation of a status change so as to orphan a status change before the incident was even created.
The text was updated successfully, but these errors were encountered: