@7365admin1/layer-common 3.2.2-staging.177 → 3.2.2-staging.178

package/CHANGELOG.md

@@ -1,5 +1,314 @@
 # @iservice365/layer-common
 
+## 3.2.6
+
+### Patch Changes
+
+- 2a4f61d: 08142026 Release new version
+
+## 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
+
+- 55160ca: Stop crashing on a null session in comments, feedback and visitor management
+
+  Several call sites read `currentUser.value._id` (and `.serviceProvider`,
+  `.type`, `.givenName`, `.surname`) with no guard. When the session is briefly
+  absent — during sign-out, on an expired session, or before the user has
+  resolved on first paint — `currentUser.value` is null and the property read
+  throws, taking the page down rather than the one action.
+
+  Those reads are now optional. Purely defensive: where a user exists the
+  behaviour is identical, and where one does not the field goes undefined instead
+  of throwing.
+
+  Covers the feedback list and its accept/submit handlers, the visitor
+  check-in/check-out path, and comment loading.
+
+## 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/VisitorForm.vue

@@ -448,6 +448,53 @@
       </v-card>
     </v-dialog>
 
+    <v-dialog v-model="dialog.returnNfcCard" max-width="450" persistent>
+      <v-card>
+        <v-toolbar density="compact" color="">
+          <v-row no-gutters class="d-flex fill-height justify-space-between align-center px-4">
+            <span class="font-weight-bold">Return NFC Card</span>
+            <v-btn icon="mdi-close" variant="text" @click="dialog.returnNfcCard = false" />
+          </v-row>
+        </v-toolbar>
+        <v-card-text class="px-4 pb-2">
+          <p class="text-body-2 mb-3">
+            Please indicate the status of the NFC card before checking out.
+          </p>
+          <div>
+            <InputLabel class="text-capitalize" title="Full Name" />
+            <v-text-field :model-value="selectedCheckoutVisitor?.name" density="comfortable" readonly />
+          </div>
+          <div>
+            <InputLabel class="text-capitalize" title="Location" />
+            <v-text-field :model-value="formatVisitorLocation(selectedCheckoutVisitor)" density="comfortable"
+              readonly />
+          </div>
+          <div v-for="(card, idx) in nfcCardReturnStatuses" :key="card.cardId" class="mb-4">
+            <div class="d-flex align-center ga-2 mb-2">
+              <v-icon size="18" icon="mdi-credit-card-outline" color="purple" />
+              <v-chip size="small" variant="tonal" color="purple">{{ card.cardNo }}</v-chip>
+            </div>
+            <v-select v-model="nfcCardReturnStatuses[idx].status" :items="nfcPassStatusOptions" item-title="label"
+              item-value="value" density="comfortable" hide-details />
+            <v-textarea v-if="card.status === 'Lost' || card.status === 'Damage'"
+              v-model="nfcCardReturnStatuses[idx].remarks" label="Remarks (required)" no-resize rows="3" class="mt-2"
+              density="compact" />
+          </div>
+        </v-card-text>
+        <v-toolbar class="pa-0" density="compact">
+          <v-row no-gutters>
+            <v-col cols="6">
+              <v-btn variant="text" block @click="dialog.returnNfcCard = false">Close</v-btn>
+            </v-col>
+            <v-col cols="6">
+              <v-btn color="red" variant="flat" height="48" rounded="0" block :loading="loading.checkingOut"
+                :disabled="!canConfirmNfcReturnCheckout" @click="handleNfcReturnCheckout">Confirm Checkout</v-btn>
+            </v-col>
+          </v-row>
+        </v-toolbar>
+      </v-card>
+    </v-dialog>
+
     <v-dialog v-if="enableUnregistered" v-model="dialog.showUnregisteredPlateDialog" max-width="900" persistent>
       <v-card class="screen-modal">
         <!-- No heading in the product; see the note on the check-out dialog. -->
@@ -641,7 +688,7 @@ const {
 } = useVisitor();
 const { getBySiteId: getEntryPassSettingsBySiteId } =
   useSiteEntryPassSettings();
-const { createVisitorPass, signQr } = useAccessManagement();
+const { createVisitorPass, signQr, visitorCheckout } = useAccessManagement();
 const { getReaders, issueVisitorQr } = useHidAmico();
 const { testConnection } = useWebUsb();
 const {
@@ -731,6 +778,7 @@ const dialog = reactive({
   vehicleNumberUsersList: false,
   showNonCheckedOutDialog: false,
   showUnregisteredPlateDialog: false,
+  returnNfcCard: false,
 });
 
 const loading = reactive({
@@ -764,6 +812,30 @@ const deliveryCompanyList = ref<string[]>([]);
 const matchingNonCheckedOutVisitors = ref<TVisitor[]>([]);
 const selectedCheckoutVisitorId = ref<string | null>(null);
 const skipNonCheckedOutNric = ref(false);
+
+const nfcCardReturnStatuses = ref<
+  { cardId: string; cardNo: string; status: string; remarks: string }[]
+>([]);
+const nfcPassStatusOptions = [
+  { label: "Returned", value: "Returned" },
+  { label: "Not Returned", value: "In Use" },
+  { label: "Damaged", value: "Damage" },
+  { label: "Lost", value: "Lost" },
+];
+const selectedCheckoutVisitor = computed(() =>
+  (matchingNonCheckedOutVisitors.value as any[]).find(
+    (v) => v?._id === selectedCheckoutVisitorId.value
+  )
+);
+const canConfirmNfcReturnCheckout = computed(() => {
+  if (nfcCardReturnStatuses.value.length === 0) return false;
+  return nfcCardReturnStatuses.value.every(({ status, remarks }) => {
+    if (!status || status === "In Use") return false;
+    if ((status === "Lost" || status === "Damage") && !remarks.trim())
+      return false;
+    return true;
+  });
+});
 const nonCheckedOutVisitorHeaders = [
   { title: "Name/NRIC", key: "name", align: "start", sortable: false },
   { title: "Type / Company", key: "typeCompany", align: "start", sortable: false },
@@ -1346,19 +1418,43 @@ async function handleSkipNricNonCheckedOut() {
   dialog.showNonCheckedOutDialog = false;
 }
 
-async function handleCheckout(visitorId: string) {
+function handleCheckout(visitorId: string) {
   if (!visitorId) {
     errorMessage.value = "Invalid visitor ID. Cannot proceed with checkout.";
     return;
   }
 
+  selectedCheckoutVisitorId.value = visitorId;
+
+  const visitor = (matchingNonCheckedOutVisitors.value as any[]).find(
+    (v) => v?._id === visitorId
+  );
+  const nfcCards = ((visitor?.cards as any[]) || []).filter(
+    (card) => card?.type === "NFC"
+  );
+
+  if (nfcCards.length > 0) {
+    nfcCardReturnStatuses.value = nfcCards.map((card: any) => ({
+      cardId: card._id,
+      cardNo: card.cardNo,
+      status: "In Use",
+      remarks: "",
+    }));
+    dialog.returnNfcCard = true;
+    return;
+  }
+
+  proceedNonCheckedOutCheckout(visitorId);
+}
+
+async function proceedNonCheckedOutCheckout(visitorId: string) {
   try {
     loading.checkingOut = true;
-    selectedCheckoutVisitorId.value = visitorId;
     const res = await updateVisitor(visitorId as string, {
       checkOut: new Date().toISOString(),
     });
     if (res) {
+      dialog.returnNfcCard = false;
       await checkNonCheckedOutVisitorsBeforeSubmit();
     }
   } catch (error: any) {
@@ -1372,6 +1468,33 @@ async function handleCheckout(visitorId: string) {
   }
 }
 
+async function handleNfcReturnCheckout() {
+  const visitorId = selectedCheckoutVisitorId.value;
+  if (!visitorId) return;
+
+  try {
+    loading.checkingOut = true;
+    const res = await visitorCheckout({
+      cards: nfcCardReturnStatuses.value.map(({ cardId, status, remarks }) => ({
+        cardId,
+        userId: visitorId,
+        status,
+        remarks: remarks ?? "",
+      })),
+    });
+    if (res) {
+      await proceedNonCheckedOutCheckout(visitorId);
+    }
+  } catch (error: any) {
+    const checkoutErrorMessage = error?.response?._data?.message;
+    console.log("[ERROR]", error);
+    errorMessage.value =
+      checkoutErrorMessage || "An error occurred while returning the NFC card.";
+  } finally {
+    loading.checkingOut = false;
+  }
+}
+
 const debounceFetchCompany = debounce(
   async () => fetchCompanyListRefresh(),
   200

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.2-staging.177",
+  "version": "3.2.2-staging.178",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "//files": "What a consumer extending this layer actually loads. Without this npm ships the whole working tree - the changesets, the CI workflows, the render harness in tools/ and any scratch directory that happened to exist at publish time. Nuxt resolves a layer by directory, so every runtime directory below has to stay listed; adding a new top-level runtime directory means adding it here too.",