# Alarm banner

> Dashboard component reference for the Alarm banner, its three presentations, every property, and how alarms are acknowledged from it.

The **Alarm banner** shows the pending slice of the alarm registry: every alarm that is
active or still awaiting an acknowledge, worst priority first, oldest first within a
priority. It is the one component that reads the registry directly — it has no address to
bind — so its panel only asks how much of the registry to show and how. It is also where
the operator answers alarms: on a full-screen dashboard there is no other page to walk to,
so the acknowledge buttons live on the banner itself.

## Presentations {#presentations}

The **Shows** property picks one of three shapes. All three are the same reading at three
sizes; the severity floor and the row cap below are applied where the registry is read, so
a summary never counts an alarm the list beside it was told to leave out.

| Option | What it draws |
|---|---|
| Every pending alarm | One row per alarm with its name, state and how long it has been pending, plus an **Ack** button per row when acknowledgement is on. |
| One line about all of them | A single sentence, for example `2 active (1 unacked)`. |
| How many at each severity | One chip per severity that has something pending, worst first, each with its total and, when acknowledgement is on, its unacked count. A severity with nothing pending draws no chip. |

The header always carries the summary line. When the banner shows nothing at all it reads
**No active alarms**; while acknowledged rows are still settling out of a list it reads
**All acknowledged** instead, so the header never reports a quiet plant over visible rows.

## Properties {#properties}

| Property | What it does | Values | Default |
|---|---|---|---|
| Shows | The presentation, as above. | Every pending alarm · One line about all of them · How many at each severity | Every pending alarm |
| Down to | The least severe priority the banner still shows. Priorities run worst-first, so this is a severity floor. It is part of the reading, not the drawing: an alarm below the floor is out of the rows, the summary, the counts and Ack all alike. | Critical only · High and worse · Medium and worse · Every priority | Every priority |
| Rows at most | How many rows the list presentation draws. What is over the cap is counted under the list (`3 more alarms are not shown.`), never dropped in silence. Only asked of the list presentation. | 1 to 200 | 20 |
| Say what awaits an acknowledge, and offer to answer it | One switch governing both halves of acknowledgement: the marks saying what still awaits an answer (the unacked half of the summary, the unacked count on a chip, the mark on a row) and the buttons that give it (the per-row **Ack** and the header's **Ack all**). Off, the banner is purely informational; on a full-screen station that also removes the only way to answer an alarm. What the alarm's own state machine is doing is never hidden by this. | on / off | on |
| Count them by severity too | Adds the per-severity chips beside the summary of the other two presentations. Not offered on the severity presentation, which is already made of them. | on / off | off |

A row count typed outside the 1–200 band is taken at the nearest edge and the panel says
so beside the field; text that is not a number leaves the cap in force alone.

## Acknowledging {#acknowledging}

Every acknowledge rides the logic queue and is journaled like any operator acknowledge.

- **Ack** on a row answers that alarm. A row already answered shows a check mark instead
  of a spent button.
- **Ack all** in the header answers everything the banner reads, one alarm at a time
  through the same funnel. The severity floor applies — the banner never answers an alarm
  it was told not to show — but the row cap does not, because the cap limits the drawing
  and the summary already counts what it holds back. The answer line then says how many
  were acknowledged; if the run of writes stops partway, it says how far it got
  (`2 of 5 acknowledged`) rather than leaving the rest pending in silence.
- On the list presentation, **Ack all** appears once more than one alarm awaits an answer
  (with a single one, the row's own button already is that command). The two summaries
  draw no rows, so there the header button appears as soon as one alarm is waiting.

After an acknowledge that removes a row from the reading (a latched alarm whose condition
has already cleared), the drawn positions hold still for about two seconds — up to six
across a burst of presses — so the row under the finger stays the row that was answered.
An alarm raised meanwhile is still drawn in whatever room the cap has left; the summary,
the counts and the rest of the app run on regardless. A settling row is styled as on its
way out rather than keeping an unacked mark it no longer earns.

## Permission {#permission}

Acknowledging takes the **Dashboard operation** permission of the signed-in local user's
role; on a unit's Process screen, the **Run procedures** permission gates it instead,
like every command that screen hosts. Without it, the banner wears the
shared lock mark and the buttons' tooltips carry the reason — but only while an answer is
actually offered and something awaits one: an informational banner, or one with nothing
pending, is a reading, and a reading does not claim the station may not command. The
transient result of each press is written on the banner itself, the one surface left when
a full-screen dashboard hides the status bar.