@7365admin1/layer-common 3.2.1 → 3.2.2-staging.77

package/.changeset/camera-wall-gated-endpoint.md

@@ -0,0 +1,47 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Draw the camera wall from the gated wall endpoint, and show the server's own
+reason on a tile.
+
+`CameraWall` fetched its cameras from `GET /api/site-cameras` - the Settings
+panel's paginated CRUD list, which took its site from an optional query
+parameter and checked nothing about the caller. Any signed-in user from any
+organisation could read every camera in the estate through it, `host` and
+`username` included.
+
+It now calls `GET /api/site-cameras/site/:siteId/wall`, which already exists,
+which the React Native monitoring app was built against, and which is
+authorised server-side: the caller must be a member of the site, of its owning
+organisation, or work for an organisation actively engaged to serve it. That
+endpoint also returns `type: "ip"` cameras only and each camera's capability
+descriptor, so a wall cannot be handed an ANPR unit and a tile can explain
+itself.
+
+Two consequences worth stating:
+
+- **The pager is gone.** The wall endpoint returns the site's cameras in one
+  answer. Paging a video wall was an artefact of borrowing the CRUD list.
+- **A tile now prefers the server's `unavailableReason`** over the reason it
+  used to work out itself. The server knows things the browser cannot - chiefly
+  "No recorder is configured for this camera's relay", which is the true answer
+  for every camera in the estate until the API host is configured, and which the
+  wall used to replace with its own guess. Offline still beats everything, since
+  it explains every tile at once.
+
+No permission gate was invented here. Each application still gates its own menu
+entry; this component draws what it is given, and the server decides.
+
+Two smaller things in the same area:
+
+- **A refused wall now says so.** The catch-all message told every failure to
+  "check your connection", which sends somebody who simply may not see that
+  site off to debug their wifi. A 401/403/404 now reads "You do not have access
+  to this site's cameras." The server answers "not yours" and "does not exist"
+  identically, so this wording does not distinguish them either.
+- **`middleware/member.ts` is removed.** It read a cookie into an unused
+  variable and did nothing else - a file named like a membership gate that was
+  not one. No page in any of the eleven web apps referenced it. The real check
+  is `plugins/secure-member.client.ts`, driven by `memberOnly` page meta, which
+  is untouched.

package/.changeset/camera-wall-plain-english.md

@@ -0,0 +1,60 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Rewrite the camera wall's detail panel for the people who read it, and stop
+repeating the same sentence four times.
+
+The panel under the tiles was written for a developer. On the live wall it
+read:
+
+> BBQ AREA
+> The video page loaded, but this browser cannot confirm a picture is arriving.
+> The player belongs to the video service and a browser cannot look inside it.
+> Judge the tile by what you can see, and report a blank or frozen picture.
+> ● Recorder responding   Last picture this server received: none yet
+> Firmware and device clock are not available: this recorder is reachable over
+> video only.
+
+Every one of those statements is true, and the screen was still wrong: it
+explained cross-origin isolation to a guard, repeated the camera's name the
+tile already showed, put a green light beside the words "none yet", and printed
+the same reason on four capability cards in a row.
+
+Changes, all copy and layout — **no behaviour, no capability gating and no
+permission check is touched**:
+
+- **The badge reads "Not confirmed"**, not "Not verified". "Not verified"
+  describes a check we failed to make; "Not confirmed" describes the picture,
+  which is the thing the reader cares about. Same claim, and the wall still
+  refuses to say "Live" until the video service reports a decoded frame.
+- **The sentence behind it is now an instruction**: "This page cannot confirm
+  the picture is arriving, so check the tile yourself. If it is blank or frozen,
+  report the camera." Why the software cannot confirm it is our problem, and it
+  has been removed from the product.
+- **The camera's name is no longer a heading of its own.** It is the subject of
+  the status line — "BBQ AREA · Recorder responding" — so a reader on a 3x3 wall
+  still knows which tile the panel describes, without a second caption under the
+  first one.
+- **"Last picture" is drawn only when there has been one.** A green "Recorder
+  responding" beside "none yet" read as a contradiction. They were never in
+  conflict, but a screen that has to be explained is wrong. The tile's own
+  health line has always behaved this way; the panel now matches it.
+- **The firmware-and-device-clock sentence is gone**, from the panel and from
+  the tile's tooltip. This screen never showed either value, so explaining their
+  absence gave the reader nothing to do. The server still sends
+  `detailUnavailableReason`; nothing draws it.
+- **One reason for the group instead of four copies.** When every switched-off
+  control is off for the same reason, that reason and its next step are stated
+  once above the row and each card keeps only its title and its state. When the
+  reasons differ — "the recorder is unreachable" and "this camera cannot move"
+  are two problems with two different people to ask — the group note is refused
+  and each card carries its own again. New rule 7, in `camera-wall.ts`, with
+  four tests.
+- Shorter next-step and no-signal wording, and a subject on the recorder's
+  status labels ("Recorder not checked yet" rather than "Health not checked
+  yet").
+
+Rules 3 and 6 are intact: the server's own sentence is still shown verbatim and
+never rewritten, and the recorder's state is still a separate fact from the
+tile's badge.

package/.changeset/camera-wall-selection-and-guidance.md

@@ -0,0 +1,65 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Mark the selected camera on the wall, and stop telling the reader to raise a
+ticket without saying what for.
+
+Two things the owner found on the live wall after the last copy pass. Both are
+copy and presentation only — **no behaviour, no capability gating, no permission
+check and no request is changed.**
+
+**1. The camera's name was still printed twice.**
+
+The tile said `BBQ AREA` and the panel underneath said it again. The last pass
+merged the panel's heading into its status line, which changed the layout and
+left the repetition exactly where it was.
+
+The name was there to answer "which of these nine tiles is this panel about?".
+That is a real question and a name is the wrong answer to it — it makes the
+reader scan the wall for a matching caption. So:
+
+- **the selected tile is now visibly selected**: a 3 px accent ring with a scrim
+  hairline inside it, so the ring holds against a bright picture as well as a
+  dark one, plus the accent underline on the name chip that the toolbar already
+  uses to mark a selected tool. Both read at 1x1, 2x2 and 3x3;
+- **the camera's name is removed from the panel entirely**. The panel opens on
+  the recorder's state — "● Recorder responding";
+- `aria-current` marks the same tile for anyone not looking at the ring.
+
+The highlight had never worked in the most common case, which is why the name
+was load-bearing: it was bound to the raw clicked id, and before anyone clicks —
+or after paging — nothing on the wall was marked while the panel was already
+describing the first tile. It is now bound to the tile the panel actually
+resolves to, so the two can never disagree.
+
+**The panel can never be about a tile that is off screen**, so it never needs to
+name one: the focused camera is resolved out of the current PAGE, so paging away
+from a selection re-resolves to the first tile of the page in front of you and
+the ring follows. Paging back restores the original selection. Extracted as
+`focusedCamera()` in `camera-wall.ts` with four tests, including the 5-cameras
+-across-2-pages case.
+
+**2. "Ask your Seven365 administrator" was a dead end.**
+
+It was the whole of the advice under every switched-off control, and it tells
+the administrator nothing and a property manager only to go and wait. The screen
+never said what the request should ask for.
+
+The advice now names the two changes that are actually missing, because they are
+two different jobs for two different people: **the site's network has to let our
+server reach the camera recorder**, and **that recorder then has to be added to
+the server's configuration**. Both are stated in plain words, with who arranges
+them, and with the fact that neither is switchable from this page.
+
+No environment variable name appears in any of it — those belong in
+`iservice365-core/docs/camera-integration-config.md`, not on a property
+manager's screen — and there is a test that keeps it that way. The other reason
+codes (`device-http-disabled`, `device-http-unreachable`, `device-http-locked-out`,
+`control-not-enabled`, `no-recorder-configured`, and the unknown-code fallback)
+get the same treatment; the Site Settings ones already said what to do and are
+unchanged.
+
+The truthful-status rules are untouched: the wall still refuses to say "Live"
+until the video service reports a decoded frame, and the recorder's state is
+still a separate fact from the tile's badge.

package/.changeset/dark-primary-contrast.md

@@ -0,0 +1,39 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Split the dark theme's `primary` into a foreground colour and a fill, so text
+using it is readable again.
+
+Dark `primary` was set to the brand navy `#17506F` so the navigation drawer
+would read as a surface. That is the right value for a fill — a white label on
+it measures 8.70:1 — but Vuetify emits `.text-primary` from the same token, so
+every `class="text-primary"` sentence and every `color="primary"` icon, spinner
+and text button rendered navy on a dark background:
+
+|                        | before | now |
+|---|---|---|
+| `primary` as text on the dark page `#0E1319`   | 2.14:1 | **6.40:1** |
+| `primary` as text on a dark card `#1B242F`     | 1.80:1 | **5.38:1** |
+| `primary` as text on `surface-bright` `#26313E`| 1.52:1 | **4.53:1** |
+
+Dark `primary` is now `#5B9BE0`. That is not a new colour: it is the blue the
+camera wall already draws its accents in (`--vms-accent`), so the two dark
+surfaces in this product agree on one blue.
+
+The navigation drawer no longer depends on `primary`. Both themes gain a
+`brand-surface` colour — `#042134` light (identical to light `primary`, so
+light mode renders exactly as before) and `#17506F` dark — and
+`Layout/NavigationDrawer.vue` is painted with it. Its white label still reads
+16.51:1 light and 8.70:1 dark. `floating` was dropped from the drawer so it
+draws its own edge: the fill is 2.14:1 against the dark page, under the 3:1 a
+boundary wants, and the border at `border-opacity` 0.35 is 3.22:1.
+
+Where `primary` is still used as a fill, Vuetify derives `on-primary` from it
+and picks black, which reads at 7.21:1. What a light `primary` cannot carry is
+a hardcoded white label, and a handful of app-side sites still set one — see
+the pull request for the list.
+
+The light theme is unchanged. The colours moved to `utils/theme.ts` and
+`utils/theme.test.ts` now measures them, so a token cannot be moved for one use
+and quietly broken for the other again.

package/.changeset/dashboard-dark-theme-contrast.md

@@ -0,0 +1,15 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Dashboard and filled-primary surfaces now follow the theme in dark mode.
+
+- `DashboardMain` painted its panels, list rows and text with fixed hex values,
+  so the ACTIVE PATROL / STAFF STATUS / Feedbacks cards rendered white on the
+  dark page and the heading and KPI figures were dark grey on near-black
+  (1.19:1). They now use the theme's surface and foreground tokens.
+- `DARK_THEME` had no `on-primary`, so Vuetify derived white for every filled
+  `primary` button, chip, alert, tab bar and snackbar - 2.91:1. It is now set
+  explicitly and measures 6.40:1.
+
+The print / PDF / Word export styles are unchanged and stay ink-on-white.

package/.changeset/service-provider-invitation-actions.md

@@ -0,0 +1,28 @@
+---
+"@7365admin1/layer-common": minor
+---
+
+Make the Pending tab's invitation actions reachable, and say which state an invitation is really in
+
+The row menu in the service-provider list was drawn only for provider rows, so a
+pending invitation offered no actions at all — including the cancel that was
+already wired up behind it. Invitation rows now carry Cancel, Resend and Delete,
+each behind a confirmation that names the company and the site, and Resend is
+disabled with the reason while Seven365 has not approved the invitation yet.
+
+Every invitation also used to read "Pending" whatever had happened to it. Rows
+now show the state they are actually in — Waiting for Seven365, Waiting for the
+provider, Not approved, Declined, Cancelled, Expired — in those words, with
+Seven365's reason shown underneath a rejected one.
+
+Also here: a new ServiceProviderInvitationPrompt, which is how an existing
+provider answers an invitation from inside the app they already use, with no
+sign-up and no one-time code.
+
+Three contrast fixes found while rendering these screens: the list's tab strip
+was a hardcoded light grey that turned into a white slab in dark mode and took
+the tab labels with it; the service type column read the raw stored slug
+("security_agency") instead of "Security"; and `on-warning`, `on-info` and
+dark's `on-error` are now set explicitly, because Vuetify derives white for them
+and that measures 2.37:1, 3.12:1 and 3.60:1 on those fills — every filled
+warning, info and error chip, alert and button in the product.