Events and history

Events is a table of every maintenance window, in two modes over the same subject. The mode is chosen with the switch at the top of the screen and rides in the URL, so a link to a particular mode is worth sending.

Mode	What it is	Cancelled events
Manage	The workbench — edit status, open the event card, cancel	Shown
History	The record — what was done, to what, by whom, and what the checklist said	Not shown

History is open to every signed-in user. Manage mode, and the switch that reaches it, appear only for those allowed to edit events. The operator who did the work is exactly who needs to look it up afterwards.

A cancelled event does not appear in history because it did not happen. Leaving it there makes "when did we last update this system" unanswerable at a glance.

The columns

The two modes share four columns and disagree about the rest, so each keeps its own column layout, saved views and rows-per-page choice.

Manage — Window · End · Update type · System name · System manager · Server · Request ID · Status.

History — Start · End · Update type · System · System manager · Performed by · Servers · Checklist · Tasks · Request ID · Created by · Status.

The Servers column shows a count, but search and filtering run over the host names themselves — which is how the search box finds the event that touched a particular machine. The Checklist column shows Complete · Partial n/m · Empty · None, and is searchable over the wording of the questions and the answers alike: people look for "who approved the freeze" by the phrasing of the question as often as by the answer.

The five statuses

Status	When
Planned	The default for a new event
In progress	The window is open, or it was marked by hand
Completed	The work finished
Failed	The work finished and did not succeed
Cancelled	The event was called off

The quick picker in the table offers four of them. Cancelled is deliberately not one of them — cancelling is what withdraws the meeting from the invitees and cancels the request, and it lives on the cancel path in the event card. An ordinary status change sends nothing: it is internal bookkeeping, not re-coordination.

Editing

The event card opens from the table and from the calendar, with three tabs: Edit (or Details, for anyone not allowed to edit), Checklist and Tasks.

Editing changes the title, the window, the servers, the manager, the contacts, the notes and the attachment. Saving updates the existing invitation in place — no duplicate meeting is created — and updates the request as well. The screen warns before saving: "Saving will send an updated invite to every contact and to the system manager."

If updating the invitation or the request fails, the event is still saved and the message states which of the two did not go through. Detail in Calendar invitations and reminders.

Moving the window also re-arms the SMS reminder, so it fires against the new time.

Cancel, then delete

Two separate actions, and only in that order.

1. Cancel marks the event as cancelled, sends a cancellation to everyone who received an invitation, and cancels the request. The event stays in the table.
2. Delete permanently removes the row and everything hanging off it — the selected servers, the tasks, the checklist, and the suggestions this event taught system memory.

The audit log is kept. It is the record that the deletion happened, and erasing it would defeat the purpose of an audit trail. The two actions require separate permissions.

To reach a cancelled event on the calendar, Show cancelled events has to be turned on — the toggle says why it exists: "required to permanently delete an event opened by mistake".