@7365admin1/layer-common 3.2.1-staging.65 → 3.2.1-staging.67

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-staging.65",
+  "version": "3.2.1-staging.67",
   "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/plugins/vuetify.ts

@@ -42,6 +42,67 @@ import {
 } from "vuetify-pro-tiptap";
 import "vuetify-pro-tiptap/style.css";
 
+/**
+ * Contrast decisions live here rather than inline, because both themes need the
+ * same two opacity corrections and a value that differs by accident between
+ * light and dark is a bug nobody sees until somebody flips the switch.
+ *
+ * `disabled-opacity`: Material's 0.38 measures 2.68:1 on white, below the 4.5:1
+ * a sentence needs, and disabled fields in this product carry sentences people
+ * are expected to read. 0.55 is 4.74:1 on white and 6.21:1 on the dark page -
+ * the same value the camera wall settled on, for the same reason.
+ *
+ * `border-opacity`: 0.12 measures 1.32:1, which is a divider you cannot see.
+ * Dark goes to 0.35 (3.22:1) and carries the boundary properly. Light goes to
+ * 0.26 (1.88:1) - visible, but short of the 3:1 a component boundary wants.
+ * Reaching it on white needs 0.42, which turns every table and card edge into a
+ * mid-grey grid across eleven applications; that is a change somebody should
+ * look at before it ships, not one to slip in behind a contrast fix.
+ */
+const LIGHT_THEME = {
+  dark: false,
+  colors: {
+    primary: "#042134",
+    "primary-button": "#1867C0",
+    "text-primary": "#052439",
+  },
+  variables: {
+    "disabled-opacity": 0.55,
+    "border-opacity": 0.26,
+  },
+};
+
+/**
+ * Only the keys that must differ; Vuetify merges the rest from its stock dark.
+ */
+const DARK_THEME = {
+  dark: true,
+  colors: {
+    /**
+     * Stock dark's #121212 page and #212121 surface measure 1.16:1 apart, so a
+     * card, a dialog and the page behind them were one flat sheet. These are
+     * 1.19:1 - elevation on a dark screen is a genuinely small delta - but they
+     * are tinted towards the brand navy rather than neutral grey, and the
+     * divider opacity above is what actually draws the edges.
+     */
+    background: "#0E1319",
+    surface: "#1B242F",
+    /** Stock dark ships a lavender #ccbfd6 here, which is not our product. */
+    "surface-bright": "#26313E",
+    "surface-light": "#26313E",
+    /** The brand navy lifted until the nav drawer is a surface, not a hole. */
+    primary: "#17506F",
+    /** Unchanged on purpose: it already passes in both themes. */
+    "primary-button": "#1867C0",
+    /** #052439 on a dark page measures 1.18:1. This is 15.72:1. */
+    "text-primary": "#E8ECF1",
+  },
+  variables: {
+    "disabled-opacity": 0.55,
+    "border-opacity": 0.35,
+  },
+};
+
 export default defineNuxtPlugin((app) => {
   const vuetify = createVuetify({
     defaults: {
@@ -69,17 +130,53 @@ export default defineNuxtPlugin((app) => {
       //   hint: "This field is required",
       // },
     },
+    /**
+     * THE PRODUCT HAS TWO THEMES, AND UNTIL NOW ONLY ONE OF THEM WAS OURS.
+     *
+     * Every app shows a light/dark toggle in the app bar (Layout/Header.vue),
+     * and it sets Vuetify's built-in "light" and "dark" themes. Those were left
+     * at Vuetify's factory values, so one click on any screen in any of the
+     * eleven apps threw the brand away: `primary` stopped being the Seven365
+     * navy and became Material blue #2196F3 - and `primary` is the navigation
+     * drawer's fill - while `primary-button` and `text-primary`, used in around
+     * eighty places across the layer and the apps, do not exist in a stock
+     * theme at all, so those components lost their colour to an undefined CSS
+     * variable. There was also no way back to the brand: the toggle only ever
+     * flipped between the two stock themes.
+     *
+     * The fix is to make the stock names OURS rather than to add new names.
+     * Several components already branch on `theme.global.name === "dark"` (this
+     * layer's FormDialog, property-management's facility icons), so a
+     * differently-named dark theme would have left every one of them silently
+     * on their light branch inside a dark app. Overriding `light` and `dark`
+     * means the toggle, `v-theme-provider theme="light"`, the `plain-dark`
+     * layout and all of those comparisons keep working, and start being right.
+     *
+     * Measured, not eyeballed - WCAG 2.1, alpha composited against the surface
+     * each value actually sits on:
+     *
+     *   text-primary on the page       dark   1.18:1 -> 15.72:1
+     *   nav drawer fill vs the page    dark   1.13:1 ->  2.14:1 (+ a real border)
+     *   white label in the nav drawer  dark   3.12:1 ->  8.70:1
+     *   primary-button vs the page     dark   3.34:1 ->  3.32:1 (unchanged)
+     *   white label on that button     both   5.61:1 ->  5.61:1 (unchanged)
+     *   disabled text                  light  2.68:1 ->  4.74:1
+     *   disabled text                  dark   3.57:1 ->  6.21:1
+     *   divider / outline              dark   1.38:1 ->  3.22:1
+     *   divider / outline              light  1.32:1 ->  1.88:1
+     */
     theme: {
-      defaultTheme: "iservice365",
+      defaultTheme: "light",
       themes: {
-        iservice365: {
-          dark: false,
-          colors: {
-            primary: "#042134",
-            "primary-button": "#1867C0",
-            "text-primary": "#052439",
-          },
-        },
+        light: LIGHT_THEME,
+        dark: DARK_THEME,
+        /**
+         * The name this product booted on before the two above carried the
+         * brand. Kept, and identical to `light`, so anything that asks for it
+         * by name - in an app that is not in this repository - still gets a
+         * theme rather than a blank one.
+         */
+        iservice365: LIGHT_THEME,
       },
     },
     icons: {

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);
+  }
+});