@7365admin1/layer-common 3.2.1-staging.72 → 3.2.1

package/plugins/secure-member.client.ts

@@ -12,40 +12,75 @@ export default defineNuxtPlugin(() => {
 
   const { userAppRole, id, orgNature } = useLocalSetup();
 
-  router.beforeEach(async (to) => {
+  router.afterEach(async (to) => {
     const isMember = to.meta?.memberOnly;
 
     if (!isMember) return;
 
     const APP = useRuntimeConfig().public.APP;
-    const org =
-      (to.params.org as string) || (to.params.organization as string) || "";
+    const org = computed(
+      () =>
+        (to.params.org as string) || (to.params.organization as string) || ""
+    );
 
-    if (!hexSchema.safeParse(org).success) {
-      return { name: "require-organization-membership" };
+    console.log('[secure-member-plugin', 'org', org.value)
+
+    if (!hexSchema.safeParse(org.value).success) {
+      return router.replace({ name: "require-organization-membership" });
     }
 
-    const userId = useCookie("user").value ?? "";
-    if (!userId) return { name: "index" };
+    const userId = computed(() => useCookie("user").value ?? "");
+
+    const { data: userMemberData, error: userMemberError } =
+      await useLazyAsyncData(
+        "plugin-get-member-by-id-" + userId.value + "-" + APP + "-" + org.value,
+        () => getByUserType(userId.value, APP, org.value),
+        { watch: [userId] }
+      );
+
+    watchEffect(() => {
+      if (userMemberError.value) {
+        console.log('running-secure-member-redirect-plugin')
+        navigateTo(
+          {
+            name: "index",
+          },
+          { replace: true }
+        );
+      }
+    });
+
+    const roleId = ref("roleId");
 
-    try {
-      const userMemberData = await getByUserType(userId, APP, org);
-      id.value = userMemberData.org ?? "";
+    watchEffect(() => {
+      if (userMemberData.value) {
+        id.value = userMemberData.value.org ?? "";
+        roleId.value = userMemberData.value.role ?? "roleId";
+      }
+    });
 
-      const [orgResult, roleResult] = await Promise.allSettled([
-        getById(org),
-        userMemberData.role ? getRoleById(userMemberData.role) : null,
-      ]);
+    const { data: getOrgByIdReq } = await useLazyAsyncData(
+      "plugin-get-org-by-id-" + org.value,
+      () => getById(org.value),
+      { watch: [org] }
+    );
 
-      if (orgResult.status === "fulfilled" && orgResult.value) {
-        orgNature.value = orgResult.value.nature ?? "";
+    watchEffect(() => {
+      if (getOrgByIdReq.value) {
+        orgNature.value = getOrgByIdReq.value.nature ?? "";
       }
+    });
 
-      if (roleResult.status === "fulfilled" && roleResult.value) {
-        userAppRole.value = roleResult.value;
+    const { data: getRoleByIdReq } = await useLazyAsyncData(
+      "plugin-get-role-by-id-" + roleId.value,
+      () => getRoleById(roleId.value),
+      { watch: [roleId] }
+    );
+
+    watchEffect(() => {
+      if (getRoleByIdReq.value) {
+        userAppRole.value = getRoleByIdReq.value;
       }
-    } catch (error) {
-      return { name: "index" };
-    }
+    });
   });
 });

package/plugins/vuetify.ts

@@ -42,8 +42,6 @@ import {
 } from "vuetify-pro-tiptap";
 import "vuetify-pro-tiptap/style.css";
 
-import { LIGHT_THEME, DARK_THEME } from "../utils/theme";
-
 export default defineNuxtPlugin((app) => {
   const vuetify = createVuetify({
     defaults: {
@@ -71,43 +69,17 @@ 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.
-     *
-     * The colours themselves, and every ratio they were chosen for, are in
-     * `utils/theme.ts`, which `utils/theme.test.ts` measures on every run.
-     */
     theme: {
-      defaultTheme: "light",
+      defaultTheme: "iservice365",
       themes: {
-        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,
+        iservice365: {
+          dark: false,
+          colors: {
+            primary: "#042134",
+            "primary-button": "#1867C0",
+            "text-primary": "#052439",
+          },
+        },
       },
     },
     icons: {

package/types/site.d.ts

@@ -1,76 +1,5 @@
 declare type TSiteCreate = Pick<TSite, "name" | "description" | "orgId">;
 
-declare type THidQrCodeFormat = "0" | "1" | "2";
-
-declare type THidPermissionCategory =
-  | "resident"
-  | "property_management"
-  | "service_provider";
-
-declare type THidPermissionAssignment = {
-  subjectId: string;
-  category: THidPermissionCategory;
-  name: string;
-  subtitle?: string;
-  intercom: boolean;
-  readerId?: string;
-  location?: string;
-  locationKey?: string;
-};
-
-declare type THidSitePermissions = {
-  orgId: string;
-  site: string;
-  readerId: string;
-  location: string;
-  assignments: THidPermissionAssignment[];
-  counts: {
-    resident: number;
-    propertyManagement: number;
-    serviceProvider: number;
-    intercom: number;
-  };
-};
-
-declare type THidPermissionCandidate = THidPermissionAssignment & {
-  selected: boolean;
-};
-
-declare type THidQrCodePassConfig = {
-  enabled: boolean;
-  onlineMode?: boolean;
-  readerId: string;
-  qrFormat: THidQrCodeFormat;
-  identificationMethods?: {
-    facial: boolean;
-    card: boolean;
-    qrCode: boolean;
-    idPassword: boolean;
-    pin: boolean;
-    bluetooth: boolean;
-  };
-  printer: {
-    vendorId: string;
-    productId: string;
-  };
-  template: {
-    header: string;
-    subtext: string;
-  };
-  validityMinutes: number | null;
-  updatedAt?: string;
-};
-
-declare type TSiteMetadata = {
-  block?: number;
-  guardPosts?: number;
-  gracePeriod?: number;
-  incidentCounter?: number;
-  incidentLogo?: string;
-  services?: Record<string, unknown>[];
-  hidQrCodePass?: THidQrCodePassConfig;
-};
-
 
 declare type TSite = {
   _id?: string;

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

@@ -1,47 +0,0 @@
----
-"@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

@@ -1,60 +0,0 @@
----
-"@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

@@ -1,65 +0,0 @@
----
-"@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

@@ -1,39 +0,0 @@
----
-"@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.