Issue a task from an event
An event often needs not a work order but a to-do for the shift: “check the leak”, “replace the sign”. In the Reports → Events panel you can issue a task straight from the event. The task enters the shift diaries the usual way and rolls on from shift to shift until someone reports it done — and the event stays linked to it all along.
Before you start
Section titled “Before you start”- Permission: issuing a task needs task:issue (the same right as issuing a task), and you must be able to open the event (report:events).
- Moving the event’s status needs event:handle. Without it the task is created, but the event’s status does not change — the panel says so beforehand.
- Precondition: the event must not be “Awaiting classification” (it has no site, so no diary the task could roll into — classify it first), and must not be closed (reopen it first).
- Open the event in the Reports → Events table (click the row). Find the Tasks section of the panel. You can also start from the shift diary: the Task — in the event panel button under the event opens this same panel with the task form (if a task can be issued; if not, the panel shows the reason). The button is shown only to users who have both task:issue and report:events.
- Press Task from this event. If the button is grey, the sentence next to it gives the reason (missing right, an event awaiting classification or closed, or no live plant at the site).
- Enter the task title (2–200 characters) and, if needed, the description (up to 2000 characters). The system automatically puts the event’s identifier in front of the description, so the diary shows where the task came from.
- If the event is site-level (it has no plant), choose the Plant whose diary the task should go to. For an event tied to a plant, the task goes to that plant’s diary.
- Press Issue task to the log. If the event’s status moves as well, the button reads Issue task and mark as in progress.
What happens to the event’s status?
Section titled “What happens to the event’s status?”The panel states the effect beforehand, next to the button. The rule is simple: a task never “downgrades” a stronger state.
| The event’s status | After the task is issued | Why |
|---|---|---|
New or Acknowledged (and you have event:handle) |
In progress | Someone is acting on it. |
| In progress | Unchanged | Already being handled. |
| Investigating | Unchanged | An investigation is the stronger state; a task does not change it. |
Any, but you lack event:handle |
Unchanged | The task is created; moving the status needs event-handling rights. |
The status move happens in the same step as creating the task: either both happen or neither. The timeline gets a “Task issued from the event” entry.
What happens to the task?
Section titled “What happens to the task?”- It is a one-time task: it enters the currently open diaries at once (the panel says how many), and rolls into the other shifts from the next shift on, as usual. Until it has entered a diary, the panel’s list says “Not in a log yet”.
- In the Tasks view the task’s source is Event.
- The panel lists the issued (live) tasks with their latest state. An archived (withdrawn) task does not count as belonging to the event — it does not block reassignment either.
Closing suggestion when every task is done
Section titled “Closing suggestion when every task is done”When all live tasks issued from the event are reported done, the panel shows a suggestion: Close as “Handled by task”… It closes nothing by itself — you decide; the button opens the usual closing step (with a reason, under the policy’s rules). The suggestion comes from the site policy switch “Suggest closing the event when its tasks are done” (on by default); when off, the panel does not suggest — see Event closing rules.
The back-link from the work order
Section titled “The back-link from the work order”If you also opened a work order from the event, the Maintenance → work order detail page shows the source event’s identifier. The link
to the content (title) and to the panel needs the event-report right (report:events) — without it you see only the identifier, and
the link is replaced by: you need the event-report right to open the event.
If it worked
Section titled “If it worked”The panel says: “Task issued — added to N open log(s) now; it rolls into later shifts from the next one.” The task appears in the Tasks section, and the timeline shows the “Task issued from the event” line.
Common problems
Section titled “Common problems”| What you see | Why | What to do |
|---|---|---|
| “Issuing a task needs the task-issuing permission.” | You lack task:issue. |
Ask your admin. |
| “No task can be issued from an event awaiting classification: it has no site or log — classify it first.” | The event has no site yet. | Classify the event first. |
| “No task can be issued from a closed event — reopen it first.” | The event is closed. | Reopen it in the panel (with a written reason). |
| “The event’s site has no active plant whose log could receive the task.” | There is no plant whose diary the task could enter. | Ask your admin to add a plant to the site. |
| “The task title must be 2–200 characters.” | The title is empty, too short or too long. | Fix the title. |
| “Choose the plant whose log should receive the task.” | No plant chosen for a site-level event. | Choose a plant. |
| “The task is created, but the event’s status does not change: you lack the event-handling permission.” | You lack event:handle. |
Not an error — ask for the right if you also want to move the status. |
Worth knowing
Section titled “Worth knowing”- A task is not a work order: to order a repair use the work-order request; the two can be used together on one event.
- Every issue leaves an audit trail (who, when, from which event).
- The diary has no separate task form for an event: the consequences of issuing a task (a block, the status effect) are about the event’s status, so the diary button takes you to the panel.
- The task shows in the diary as usual; the event’s status still does not — it appears only in the Events table, the panel and the export (see Handle events from the table).