Handle events from the table

The Reports / Export → Events table is not only for looking events up: click a row and the event opens in a side panel, where you can change its status, add a comment and — if your rights allow — edit its content. Every step leaves a trace on the event’s timeline.

Before you start

Opening an event needs the report:events right (or one of the handling/editing rights below).
Changing the status and commenting: event:handle. Editing the content: event:edit. By default the shift leader, the plant-group manager, the production manager and the site manager have them; the admin can switch them on for other roles (for example an HSE role) in the permission matrix.
The conditions of closing — whether a written justification is needed, what must happen first for an accident — come from the site’s policy (Event closing rules).

The table and the filters

By default the Events tab shows the open events (New, Acknowledged, In progress, Investigating). Its columns are Event ID, Status (with the closing reason underneath), Time, Type (with the subcategory, if the event has one), Severity, Title, Reporter and Link.

Status badge: a New · N days badge means the event has waited untouched for longer than the number of days set in the policy.
Source badge under the title: Recorded outside the shift log, Field report — unverified or Automatic. An event recorded in the shift diary has no badge.
Link: the work order (CMMS), permit, task or field report it is tied to. The work-order and permit links appear only if that module is switched on.

The Filters bar above the table is collapsible; its heading shows what is set.

Filter	What it does
Status	Open (default), All, or one or more individual statuses.
Closing reason	Among the closed events, those closed with the given reason. If you pick no status, the table switches to Closed with it (open events have no closing reason).
Source	In the shift log · Recorded outside the shift log · Field report · Automatic.
Severity	Near miss · Incident · Accident.
Type	One or more event types — from your organization’s type list, in your admin’s order, custom types included. An archived type is a filter too, marked “· archived”, so older events can still be filtered by it.
Subcategory	The subcategories of the selected type(s) appear; with several types they read “type · subcategory”. An archived subcategory is a filter too (“· archived”).
Module link	Work order · Permit · Task · Field report · No link (Work order and Permit only for modules that are switched on).
New for too long	Only “New” events older than the configured number of days.

A Subcategory filter narrows only its own type: if you select two types and tick a subcategory under just one of them, that type keeps only the events of the ticked subcategory, while every event of the other type stays. If you remove a type from the filter, its subcategory filters drop out with it. The Open button also clears a closing-reason filter (that could only match closed events).

Reset filters returns to the open view. The filters live in the browser address (URL), so you can send the configured view to a colleague, and the export follows the same filtering. If the list is very long, the table shows the latest rows and says so — narrow down to reach older ones.

Steps

On the Events tab click a row, or the Event ID button. On the right (full screen on a phone) the event’s panel opens: the ID, title, details and description. Close it with Esc or the close button.
Change the status. The Status section has buttons for the transitions possible from the current state (for example Acknowledge, Start handling, Start investigation, Close). Pick one:
- To close, a closing reason must be chosen; the policy may also ask for a written justification.
- If a policy rule blocks the step (for example nobody has reviewed an accident yet), the button is greyed out and the rule’s name shows why it is not possible.
- If a rule only warns, you have to write a justification for the step.
- A closed event is reopened with Reopen (the event becomes Acknowledged); a written reason is mandatory for it. Press the Save: … button (its label names the new status); the change goes onto the timeline.
Comment. In Timeline and comments write into the box and press Add comment. A comment can not be edited or deleted afterwards.
Edit. The Edit button lets you change the title, description, type, subcategory, HSE severity, installation location, the Downtime / Production loss flags and the event’s start and end. After saving, the change shows on the timeline field by field (what it was, what it became, who, when).

Correcting an event tied to a closed diary

What you may change depends on whether the shift diary the event belongs to is closed. A diary counts as closed as soon as it is no longer a draft: whether it was finalized by hand or closed automatically as incomplete at the end of the shift. A closed diary is an official record, so its content cannot be rewritten silently.

The event’s diary	What you can do	Required right
Open (still a draft)	Edit the event’s content freely. Every change goes onto the timeline field by field.	event:edit
Closed	You can always add a comment — it does not change the diary’s content.	event:handle
Closed	A content fix only as a correction, with a mandatory justification.	event:edit and shift_log:correct
Field report (QR)	The original text cannot be edited — a supplement is the way (see below).	—

Who can make a correction? By default the diary-correction right belongs to the management roles: the plant-group manager, the site manager, the data supervisor and the system administrator. The shift leader and the production manager do not have it by default — for an event of a closed diary they can write a comment, and must ask a colleague with the correction right to fix the content. The admin can change the roles’ diary-edit scope for the organization; the panel always shows the button your right allows (Edit, Correction, or only the comment box).

What happens in a correction?

Open the event in the panel and press the Correction button.
Change the fields and write the justification (mandatory — the system will not save without it).
Save. The change shows on the timeline field by field: what it was, what it became, who and when — marked as a correction, with the justification.
The diary’s PDF gets a new version: the earlier one stays as superseded, it is not overwritten. The next download already carries the corrected content.

If you only want to flag that something is inaccurate and you have no correction right, write a comment — that always works and does not touch the diary’s content.

Moving an event to another site

If an event was recorded in the wrong place, or is “Awaiting classification” (a company-level report with no site), you can move it in the panel with the event:reassign permission — with a mandatory reason; it gets a new identifier and the old one stays searchable as the “Previous ID”. Moving is blocked while a work order, permit or task is linked, and for an event of a closed log it is a correction. Details: Move an event to another site.

Task from the event

In the panel’s Tasks section you can issue a task from the event to the shifts (task:issue): the task enters the diaries and the event — if it is not already in progress — moves to In progress (this needs event:handle). When every task is done, the panel suggests closing (“Handled by task”). Details: Issue a task from an event. The Task — in the event panel button on a diary event brings you here, with the task form.

Work request from the event

In the panel’s Work request section you can open a maintenance work request from the event — with the same rule as in the diary (cmms:wo:request, Maintenance module on). For an event without a location you pick the functional location here; if a live request exists, the disabled button says so (with its number if you can see that work order). Details: Opening a work order request from an event.

Photos on the event

In the panel’s Photos section you can attach one or more photos to the event, just as under the event in the shift diary — the photo becomes part of the log and appears among the log’s photos and in the PDF.

Permission: event recording (event:create) and write access to the log of the event’s plant. Without it you can only view the photos already attached.
Closed log: a photo can be attached only with the log-correction right; the log PDF then gets a new version.
Not possible (the greyed-out box gives the reason): for an event “Awaiting classification” (classify it first), and for now for an event outside a shift log (e.g. a site-level field report).
If photos are switched off for the plant, the section does not appear.

A field report

The original text of a field report sent in by QR code cannot be edited. If more information is needed, a supplement is the way (it shows as a separate item on the timeline), and the handler can add a comment.

A report from a site-level reporting channel lands here too: with status New, two badges (Field report — unverified and Recorded outside the shift log), and no diary entry. The panel shows the reporter’s suggested place and kind (the kind is only a suggestion — you set the type); the reporter’s name and contact are visible only with the “Manage field reports” right. Details: Field report by QR label.

Where does the status show?

The status and the closing reason are visible in the Events table, in the side panel and in the export. In the diary (live and archived) and in the shift PDF they are deliberately not shown: there only the event’s ID (and the source badge, as a fact) appears — so the content of a closed diary and its PDF does not change because the event’s fate develops later.

If it worked

The status changes to the new value in the table row and on the panel’s timeline, and a closed event leaves the default view (you see it with the All or Closed filter). The export contains the Event ID, Status and Closing reason columns.

Common problems

What you see	Why	What to do
Status buttons are grey, “You have no right to handle the event”	You lack the `event:handle` right.	Ask your admin. Opening needs only `report:events`.
A button is grey: “not possible — …”	A blocking policy rule is not met.	Meet the condition (for example the review of the accident), or ask for the rule to be changed.
“The event’s status changed in the meantime …”	Someone else changed the event meanwhile.	Look at the fresh state on the panel and try again.
“A closing reason must be chosen.”	No reason is selected when closing.	Pick a reason from the list.
“A written justification is needed for this step.”	The policy or the chosen reason asks for text (always when reopening).	Write the justification.
“The diary is closed: only a comment can be added here.”	The event belongs to a closed diary and you have no correction right.	Add a comment, or ask a colleague with the diary-correction right to make the correction.
“The original text of a field report cannot be edited.”	The content of a field report is protected.	Use a supplement or a comment.
I cannot find the closed event	The default view shows only open events.	Under Filters choose the All or Closed status.

Good to know

The timeline only grows. Status changes, comments, supplements, edits and corrections cannot be deleted; the key steps of the linked work order (request, approval, start, technically complete, closed) also show on it.
The server decides the rights. If a button is unavailable, the screen says why; the rules come from the policy.
An event can be opened by a direct link (the browser address carries the event’s ID), so you can send it to a colleague.

Review and export eventsThe table, the search and the CSV/Excel export.

Event closing rulesPolicy and closing reasons — what you use here.