@7365admin1/layer-common 3.2.3 → 3.2.5

package/CHANGELOG.md

@@ -1,5 +1,256 @@
 # @iservice365/layer-common
 
+## 3.2.5
+
+### Patch Changes
+
+- 1d6b57b: 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.
+
+- e3b3cd7: 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.
+
+- a02619c: 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.
+
+- 9fdc87b: A shared CCTV camera wall for the web apps
+
+  `CameraWall.vue` and `CameraWallTile.vue` draw a site's cameras as a monitoring
+  wall, with the layout, tile state and refresh behaviour in `utils/camera-wall.ts`
+  so it can be measured by a test rather than only seen.
+
+  The wall is drawn from the site-scoped camera endpoint, so it shows the cameras
+  of the site the operator is actually on and nothing else. Property Management
+  and Security both mount the same component instead of each growing their own.
+
+  Also removes `middleware/member.ts`, a route middleware that read a cookie into
+  an unused variable and did nothing else. Nothing in this layer or in either
+  consuming app referenced it.
+
+- 9fdc87b: Camera wall status made honest, plus zoom, health and paging
+
+  **A tile that used to say "Live" may now say "Not confirmed", and that is the
+  point.** The badge was never measured — it said "Live" because a tile had been
+  rendered, not because anything had confirmed the camera was answering. A camera
+  that had been down for a week still read as Live. Status is now reported from
+  what was actually observed, so a tile only claims Live when the health check
+  says so, and says "Not confirmed" when nothing has come back yet.
+
+  **Tell QA before this ships.** The honest badge reads as a regression if you are
+  not expecting it: the wall will look like it has _lost_ status on cameras that
+  previously appeared healthy, when in fact those tiles were never measuring
+  anything.
+
+  Also adds zoom on a tile, per-camera health, and paging for sites with more
+  cameras than fit a screen.
+
+## 3.2.4
+
+### Patch Changes
+
+- ec40e1f: 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.
+
+- e3dd56c: The light and dark themes are ours, not Vuetify's factory pair
+
+  Only a handful of colours were being overridden, so everything else fell through
+  to Vuetify's defaults. One click of the light/dark toggle threw the Seven365
+  brand away across all 11 web apps and replaced it with stock Material colours.
+
+  Both themes now define their full palette — surfaces, text, borders, states —
+  so the toggle switches between two deliberate looks instead of switching the
+  brand off.
+
+  The light theme is unchanged in appearance. The work is in making it explicit
+  rather than inherited, so a Vuetify default can no longer leak through.
+
 ## 3.2.3
 
 ### Patch Changes