@7365admin1/layer-common 3.2.1 → 3.2.2

package/CHANGELOG.md

@@ -1,5 +1,38 @@
 # @iservice365/layer-common
 
+## 3.2.2
+
+### Patch Changes
+
+- d81dc2e: Camera-fault alerts get their own snackbar instead of riding the visitor one
+
+  Camera health was being sent through `showTransientMessage`, the same path as
+  unregistered-visitor plate alerts. That path returns early when the site has
+  the unregistered-visitor snackbar switched off, so **two of the five ANPR sites
+  were being told nothing at all when a camera went down** — the setting that
+  silenced them has nothing to do with cameras. The old snackbar was also hidden
+  whenever the operator was on the Unregistered tab.
+
+  Camera health is now its own alert, gated only on the permission to view
+  visitor data. It cannot be silenced by the unregistered-visitor switch and is
+  not hidden on that tab.
+
+  Several cameras failing at once collapse into a single line — "N cameras at
+  this site are not responding … Open Site Settings > Cameras to see which" —
+  rather than one snackbar per camera. Faults are keyed by camera id, so a repeat
+  for the same camera replaces its line instead of stacking another.
+
+  When a camera comes back, the operator who was told it was down is told it
+  recovered; the alert clears on its own.
+
+  Reads the optional `event` (`camera-fault` / `camera-recovered`) and `camera`
+  fields added to the socket payload in `@7365admin1/core`. Both are optional —
+  against an older API-core that sends a bare `message`, this behaves as it does
+  today and treats it as a fault.
+
+  **Expect an alert burst on first release** from the sites that were silent.
+  Warn the client before shipping.
+
 ## 3.2.1
 
 ### Patch Changes

package/components/VisitorSocketPopUp.vue

@@ -66,6 +66,29 @@
       </template>
     </v-snackbar>
 
+    <!--
+      Camera health is its own alert, deliberately separate from the plate
+      snackbar above: it is not a visitor event, it must not be silenced by the
+      unregistered-visitor switch, and it must not be hidden on the unregistered
+      tab. Several failing cameras collapse into one line rather than one
+      snackbar each.
+    -->
+    <v-snackbar
+      v-if="canViewVisitor"
+      v-model="cameraAlert.modal"
+      :color="cameraFaults.size ? 'warning' : 'success'"
+      :timeout="10000"
+      location="top right"
+      class="rounded-xl"
+      multi-line
+      :z-index="100000000"
+    >
+      <span class="text-1-4rem">{{ cameraAlertText }}</span>
+      <template #actions>
+        <v-btn icon="mdi-close" variant="text" @click="cameraAlert.modal = false" />
+      </template>
+    </v-snackbar>
+
     <v-dialog v-model="permanentMessageDialog.modal" max-width="480" persistent>
       <v-card>
         <v-card-title class="text-h6">Notice</v-card-title>
@@ -132,6 +155,36 @@ const permanentMessageDialog = reactive({
   text: "",
 });
 
+// Outstanding camera faults for this site, keyed by camera id so a repeat for
+// the same camera replaces its line instead of adding another.
+const cameraFaults = reactive(new Map<string, string>());
+const cameraRecovery = ref("");
+const cameraAlert = reactive({ modal: false });
+
+const cameraAlertText = computed(
+  () => cameraAlertMessage([...cameraFaults.values()]) || cameraRecovery.value
+);
+
+const handleCameraHealth = (data: TVisitorSocketData) => {
+  // Older API-core builds send the fault text with no `event`, so a bare
+  // message is a fault.
+  if (data?.event === "camera-recovered") {
+    // Without a camera id there is no way to tell which fault cleared.
+    if (data?.camera) cameraFaults.delete(data.camera);
+    else cameraFaults.clear();
+    // Alerts are now infrequent, so the operator is told it came back —
+    // otherwise the only signal a camera recovered is silence.
+    cameraRecovery.value = cameraFaults.size ? "" : data?.message || "";
+    cameraAlert.modal = Boolean(cameraAlertText.value);
+    return;
+  }
+
+  if (!data?.message) return;
+  cameraRecovery.value = "";
+  cameraFaults.set(data?.camera || data.message, data.message);
+  cameraAlert.modal = true;
+};
+
 watch(
   () => props.siteId,
   async (siteId) => {
@@ -233,8 +286,9 @@ const connectSocket = () => {
     }
 
 
-    if (data?.message) {
-      showTransientMessage(data.message, "error");
+    // Camera health, not a visitor event: its own alert, its own gate.
+    if (data?.message || data?.event) {
+      handleCameraHealth(data);
     }
 
     if (data?.messagePermanent) {

package/composables/useVisitorSocket.ts

@@ -5,6 +5,32 @@ export type TVisitorSocketData = {
   message?: string;
   messagePermanent?: string;
   reload?: boolean;
+  /**
+   * Camera health. Sent alongside `message` by API-core so the client can group
+   * or clear an alert per camera instead of matching on the message text.
+   * Absent on older API-core builds — treat a bare `message` as a fault.
+   */
+  event?: "camera-fault" | "camera-recovered";
+  /** The camera the `event` is about. */
+  camera?: string;
+};
+
+/**
+ * One line for however many cameras are currently down.
+ *
+ * A site with several ANPR cameras could otherwise raise one alert per camera
+ * at the same moment. The single-camera case shows the server's own message,
+ * which names the camera; beyond that, naming them all in a snackbar is worse
+ * than sending the operator to the page that lists them.
+ */
+export const cameraAlertMessage = (messages: string[]): string => {
+  if (!messages.length) return "";
+  if (messages.length === 1) return messages[0] as string;
+  return (
+    `${messages.length} cameras at this site are not responding. Plate reads ` +
+    `and automatic barrier opening are stopped for them. Open Site Settings > ` +
+    `Cameras to see which.`
+  );
 };
 
 export const useVisitorSocket = () => {

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.1",
+  "version": "3.2.2",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "publishConfig": {
@@ -14,6 +14,7 @@
     "build": "nuxt build .playground",
     "generate": "nuxt generate .playground",
     "preview": "nuxt preview .playground",
+    "test": "esbuild composables/useVisitorSocket.ts --format=esm --outfile=test/.build/useVisitorSocket.mjs --log-level=error && node --test \"test/*.test.mjs\"",
     "release": "yarn run build && changeset publish"
   },
   "devDependencies": {

package/test/visitor-socket.test.mjs

@@ -0,0 +1,36 @@
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { cameraAlertMessage } from "./.build/useVisitorSocket.mjs";
+
+/*
+ * The reported symptom was one camera raising a red toast every 10 seconds on
+ * an unrelated page. API-core now paces the alert; this side has to make sure
+ * several cameras failing at once still cannot become several snackbars.
+ */
+
+test("nothing is shown when no camera is down", () => {
+  assert.equal(cameraAlertMessage([]), "");
+});
+
+test("one failing camera shows the server's own message, which names it", () => {
+  const text = "The entry and exit ANPR camera at Seventh Condominium is not responding.";
+  assert.equal(cameraAlertMessage([text]), text);
+});
+
+test("several failing cameras collapse into a single line", () => {
+  const many = ["camera one is down", "camera two is down", "camera three is down"];
+  const text = cameraAlertMessage(many);
+  assert.match(text, /^3 cameras at this site are not responding/);
+  for (const message of many) assert.doesNotMatch(text, new RegExp(message));
+});
+
+test("the collapsed line points at the page that lists them", () => {
+  assert.match(cameraAlertMessage(["a", "b"]), /Site Settings > Cameras/);
+});
+
+test("no camera message tells the operator to deactivate anything", () => {
+  for (const messages of [["a camera is down"], ["a", "b"]]) {
+    assert.doesNotMatch(cameraAlertMessage(messages), /inactive|deactivat/i);
+  }
+});