@7365admin1/layer-common 4.149.2 → 4.151.0

package/composables/useHidAccessPermission.ts

@@ -1,124 +1,219 @@
+import { permissionsDenied } from "../utils/module-routes";
+
 /**
- * WHO MAY REACH THE SIX HID `access-mgmt` SCREENS.
- *
- * `pages/[org]/[site]/access-mgmt/{access-logs, administrator, hid-cards,
- * hid-readers, hid-users, intercom}/index.vue` shipped with
- * `middleware: ["01-auth","02-org"], memberOnly: true` and no permission check
- * at all. Every one of the eleven Nuxt apps inherits all six, so that was 66
- * routes on which any member of any organisation could type the URL and reach
- * door access, biometric enrolment, physical cards and the access log. The menu
- * that links five of them (`useHidNavigation`) is gated on
- * `getHidServiceEnabled(site)` -- a SITE SERVICE FLAG, not a permission -- so
- * the menu was never a boundary either.
+ * WHO MAY DO WHAT ON HID: the five flags every HID screen, menu and button asks.
  *
- * ## Why adding this gate cannot lock anybody out
+ * Decision of 2026-10-16. HID has its own permission resource, `hid-mgmt`, with
+ * five actions. Core defines the lists in `src/utils/hid-access.util.ts` and
+ * every `/api/access-management/hid` route reads them; this package does not
+ * depend on `@7365admin1/core`, so the strings are copied here and
+ * `test/hid-access-gate.test.mjs` pins the copy to the five.
  *
- * Every data call these screens make goes through `useHidAmico` to
- * `/api/access-management/hid`, and every route there carries `requireAuth`
- * plus `authorizeView` or `authorizeManage`. Those resolve through
- * `authorizeHidAccess` (`core/services/hid-amico.service.ts`) to the lists in
- * `core/utils/hid-access.util.ts` -- the nine `access-card-mgmt` strings below.
+ *   canUseHid             hid-mgmt:use-hid-access      own QR, face, PIN, card,
+ *                                                       intercom; the HID QR Code page
+ *   canViewHid            hid-mgmt:see-all-hid         open any HID admin screen
+ *   canManageHidReaders   hid-mgmt:manage-hid-readers  add, configure, test, sync,
+ *                                                       remove readers
+ *   canManageHidUsers     hid-mgmt:manage-hid-users    enrol and remove people,
+ *                                                       cards, PINs, access groups
+ *   canManageHidSettings  hid-mgmt:manage-hid-settings HID on or off, QR configuration
  *
- * WARNING: there are TWO different `HID_MANAGE_PERMISSIONS` in `core` and they
- * are NOT the same list. `hid-amico-authz.util.ts` exports
- * `["site-settings:manage-entry-pass"]`; `hid-access.util.ts` exports the
- * `access-card-mgmt` family. `hid-amico.service.ts` imports the one from
- * `hid-access.util.ts` -- and `authorizeSiteForCaller`'s own doc comment is
- * stale and still claims the other. Follow the import, not the name.
+ * ## The rules, in the order each flag applies them
  *
- * So a member holding none of these strings already gets a 401 on every list
- * call on all six screens: the screens are non-functional for them today, and
- * they see chrome plus an error toast. The set this gate refuses is a strict
- * SUBSET of the set the server already refuses in production, which is a
- * stronger guarantee than the usual widen-never-swap argument because it is
- * anchored on live server behaviour rather than on a role census.
+ *   1. No role loaded: false. `userAppRole` is null on the first tick for
+ *      everyone, the `*` owner included; `HidEnabledGate` waits on
+ *      `isAppRoleResolved` before it draws a refusal.
+ *   2. The client's module list (RP-5): `hid-mgmt` denied closes every flag,
+ *      including for a wildcard role. A wildcard role is exactly the role a
+ *      module list exists to narrow, so this is asked BEFORE the `*` check.
+ *   3. `*` passes every flag.
+ *   4. An EMPTY permission list passes nothing. This is deliberately not the
+ *      estate rule `hasPermission` applies (`grantsPermission`: empty means
+ *      everything). The owner's decision for HID is strict on empty, everywhere,
+ *      so the empty list is refused here before `hasPermission` can widen it.
+ *   5. Either manage right implies view: a role holding only
+ *      `manage-hid-readers` could otherwise create a reader and not list them.
+ *      Settings does NOT imply view, and use implies nothing.
  *
- * `site-settings:manage-entry-pass` is unioned in -- it is what
- * `hid-amico-authz.util.ts` enforces on the entry-pass paths and the string the
- * HID menu has always been associated with -- and `*` keeps its short-circuit.
+ * ## The alias period
  *
- * ## Intercom is gated with the other five
+ * Until the live roles are backfilled onto `hid-mgmt`, core still accepts the
+ * Access Cards strings HID borrowed before, at the levels
+ * `HID_LEGACY_VIEW_PERMISSIONS` and `HID_LEGACY_MANAGE_PERMISSIONS` give them:
+ * `see-all-card`, `see-all-qr-tagging` and `view` open the admin screens; the
+ * five card write strings and `manage-hid` manage readers and users; only
+ * `manage-hid` reaches settings. The same strings pass here at the same levels,
+ * so nothing that works today stops working before the backfill. The follow-up
+ * that drops the aliases deletes the `legacy*` branches below and the two
+ * `RETIRED_PERMISSIONS` in `constants/permissions.ts` together.
  *
- * `intercom` was the one screen that might have lived entirely on
- * `authorizeMember` endpoints (`/intercom/status`, `/intercom/call`,
- * `/intercom/hangup`). It does not. `HidIntercomManagement.reload()` opens with
- * `getReaders()` (`GET /readers`, `authorizeView`) and filters its rows out of
- * that response; the contacts tab, the dial-code dialog, the make-call dialog
- * and the web phone are all reached from a row, and `loadSipAccount()` is only
- * ever called from one of those dialogs. Without `authorizeView` the screen is
- * an empty table and an error, so gating it removes nothing that works.
+ * `site-settings:manage-entry-pass` is Entry Pass only again. It opened the HID
+ * screens from 4.2.14 to this release because a core utility of the same name
+ * once listed it; it never opened a HID endpoint.
  *
  * ## Drawing, not securing
  *
- * The server re-decides every HID call on its own. This hides screens that do
- * not work; it does not add protection the API does not already have.
+ * The server re-decides every HID call on its own. These flags hide screens and
+ * buttons that would be refused; they add no protection the API lacks.
  */
 
 /**
- * The nine strings `core/utils/hid-access.util.ts` enforces, view + manage.
- *
- * Written out in full `resource:action` form on purpose. `permission-vocabulary`
- * harvests what this package checks by reading literals out of the source, and a
- * bare action fed through a loop into `hasPermission(role, cat, "access-card-mgmt",
- * action)` is invisible to it. Spelling the strings out keeps all nine visible.
+ * Written out in full `resource:action` form on purpose: `permission-vocabulary`
+ * harvests what this package checks by reading literals out of the source, and
+ * a string built from a loop is invisible to it.
  */
-const HID_PERMISSIONS = [
+export const HID_RESOURCE = "hid-mgmt";
+
+export const HID_PERMISSION_STRINGS = [
+  "hid-mgmt:use-hid-access",
+  "hid-mgmt:see-all-hid",
+  "hid-mgmt:manage-hid-readers",
+  "hid-mgmt:manage-hid-users",
+  "hid-mgmt:manage-hid-settings",
+] as const;
+
+/** Core `HID_LEGACY_VIEW_PERMISSIONS`: open the admin screens during the alias period. */
+export const HID_LEGACY_VIEW_PERMISSIONS = [
   "access-card-mgmt:see-all-card",
   "access-card-mgmt:see-all-qr-tagging",
   "access-card-mgmt:view",
+] as const;
+
+/** Core `HID_LEGACY_MANAGE_PERMISSIONS`: manage readers and users during the alias period. */
+export const HID_LEGACY_MANAGE_PERMISSIONS = [
   "access-card-mgmt:add-access-card",
   "access-card-mgmt:update-access-card",
-  "access-card-mgmt:replace-access-card",
   "access-card-mgmt:delete-access-card",
   "access-card-mgmt:assign-access-card",
+  "access-card-mgmt:replace-access-card",
   "access-card-mgmt:manage-hid",
 ] as const;
 
-const HID_ACTIONS = HID_PERMISSIONS.map((p) => p.split(":")[1]);
+const HID_ACTIONS = HID_PERMISSION_STRINGS.map((p) => p.split(":")[1]);
+const LEGACY_ACTIONS = [...HID_LEGACY_VIEW_PERMISSIONS, ...HID_LEGACY_MANAGE_PERMISSIONS].map(
+  (p) => p.split(":")[1],
+);
 
 export function useHidAccessPermission() {
   const { hasPermission } = usePermission();
-  const { siteSettingsPermissions } = useCommonPermissions();
-  const { userAppRole } = useLocalSetup();
+  const { userAppRole, userAppModulesDenied } = useLocalSetup();
 
-  // `hasPermission` needs BOTH the role's string AND a catalogue entry for it:
-  // a resource missing from the catalogue is a dead gate however the role is
-  // granted. `access-card-mgmt` exists in no shared catalogue composable, so it
-  // is built here, exactly as `useServiceProviderPermission` builds its own.
+  // `hasPermission` needs BOTH the role's string AND a catalogue entry for it.
+  // The property and security catalogues carry `hid-mgmt`, the five service
+  // catalogues (cleaning, landscaping, pest control, pool maintenance and,
+  // since 2026-10-19, M&E) carry only `use-hid-access`, and no catalogue
+  // offers the retired `view` and `manage-hid` any more, so the lookup table
+  // is built here: these flags must answer the same in every app that mounts
+  // a HID screen.
   const permissions: TPermissions = {
+    "hid-mgmt": Object.fromEntries(
+      HID_ACTIONS.map((action) => [action, { check: true, description: `HID: ${action}.` }]),
+    ),
     "access-card-mgmt": Object.fromEntries(
-      HID_ACTIONS.map((action) => [
+      LEGACY_ACTIONS.map((action) => [
         action,
-        {
-          check: true,
-          description: `Allows the user to reach the HID access management screens (${action}).`,
-        },
+        { check: true, description: `HID alias period: access-card-mgmt:${action}.` },
       ]),
     ),
-    "site-settings": siteSettingsPermissions,
   };
 
+  // `?.` on purpose: an app pinned to an older layer-common, or a caller that
+  // stubs `useLocalSetup` without this field, hands back `undefined` here. That
+  // must mean "nothing denied", never a TypeError inside every gate.
+  const moduleDenied = (...modules: string[]) =>
+    permissionsDenied(modules, userAppModulesDenied?.value);
+
   /**
-   * Can this member open a HID `access-mgmt` screen at all? Any single string
-   * the server accepts is enough -- somebody granted only `delete-access-card`
-   * still has to open the screen to use it.
+   * Rules 1 to 4. `null` means "decide from the strings"; a boolean is final.
+   * The empty list is refused HERE because `hasPermission` would admit it.
    */
-  const canAccessHidScreens = computed(() => {
+  function decided(): boolean | null {
     const role = userAppRole.value;
     if (!role) return false;
-    if (role.permissions.includes("*")) return true;
-    if (hasPermission(role, permissions, "site-settings", "manage-entry-pass")) return true;
-    return HID_ACTIONS.some((action) =>
-      hasPermission(role, permissions, "access-card-mgmt", action),
-    );
-  });
-
-  // Only the gate is returned. `isAppRoleResolved` is deliberately NOT
-  // re-exported: `gate-defaults.test.mjs` sweeps every ref a permission
-  // composable returns and requires it to read false for an unresolved role,
-  // which a "has the lookup finished" flag is not. Callers that need it take it
-  // from `useLocalSetup()`, which is where it lives.
-  return { canAccessHidScreens };
+    if (moduleDenied("hid-mgmt")) return false;
+    const held: unknown = role.permissions;
+    if (!Array.isArray(held) || !held.length) return false;
+    if (held.includes("*")) return true;
+    return null;
+  }
+
+  // Only reached once `decided()` has answered `null`, so the role is loaded.
+  const has = (resource: string, action: string) => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, resource, action);
+  };
+
+  // The alias period, string by string so both source sweeps can see them.
+  const legacyView = () =>
+    has("access-card-mgmt", "see-all-card") ||
+    has("access-card-mgmt", "see-all-qr-tagging") ||
+    has("access-card-mgmt", "view");
+  const legacyManage = () =>
+    has("access-card-mgmt", "add-access-card") ||
+    has("access-card-mgmt", "update-access-card") ||
+    has("access-card-mgmt", "delete-access-card") ||
+    has("access-card-mgmt", "assign-access-card") ||
+    has("access-card-mgmt", "replace-access-card") ||
+    has("access-card-mgmt", "manage-hid");
+  const legacySettings = () => has("access-card-mgmt", "manage-hid");
+
+  // The five, each as a literal `hasPermission` call so the gate sweep
+  // (`gate-defaults.test.mjs`) and the vocabulary sweep both read them.
+  const useHid = () => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, "hid-mgmt", "use-hid-access");
+  };
+  const viewHid = () => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, "hid-mgmt", "see-all-hid");
+  };
+  const manageReaders = () => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, "hid-mgmt", "manage-hid-readers");
+  };
+  const manageUsers = () => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, "hid-mgmt", "manage-hid-users");
+  };
+  const manageSettings = () => {
+    const role = userAppRole.value;
+    return Boolean(role) && hasPermission(role, permissions, "hid-mgmt", "manage-hid-settings");
+  };
+
+  /** The user side: HID Access in the app, own QR, face, PIN, card, intercom. */
+  const canUseHid = computed(() => decided() ?? useHid());
+
+  /** Any manage right implies view (rule 5). */
+  const canManageHidReaders = computed(() => decided() ?? (manageReaders() || legacyManage()));
+  const canManageHidUsers = computed(() => decided() ?? (manageUsers() || legacyManage()));
+  const canViewHid = computed(
+    () =>
+      decided() ??
+      (viewHid() || legacyView() || manageReaders() || manageUsers() || legacyManage()),
+  );
+
+  /** HID on or off for the site, and the HID QR code configuration. */
+  const canManageHidSettings = computed(() => decided() ?? (manageSettings() || legacySettings()));
+
+  /**
+   * @deprecated The pre 2026-10 single gate: "may this member open a HID admin
+   * screen". Kept for any app on this layer that still reads it; it is
+   * `canViewHid` and nothing else. Use the five flags above.
+   */
+  const canAccessHidScreens = canViewHid;
+
+  // `isAppRoleResolved` is deliberately NOT re-exported: `gate-defaults.test.mjs`
+  // sweeps every ref a permission composable returns and requires it to read
+  // false for an unresolved role, which a "has the lookup finished" flag is not.
+  // Callers that need it take it from `useLocalSetup()`, which is where it lives.
+  return {
+    canUseHid,
+    canViewHid,
+    canManageHidReaders,
+    canManageHidUsers,
+    canManageHidSettings,
+    canAccessHidScreens,
+  };
 }
 
 export default useHidAccessPermission;

package/composables/useHidAmico.ts

@@ -204,6 +204,22 @@ export default function useHidAmico() {
     });
   }
 
+  /**
+   * The readers a member may enrol THEMSELVES on: the site's enabled readers
+   * with a portal, each with its credential capabilities, and nothing else.
+   *
+   * The self service screens (own QR, face, PIN, card) load this instead of
+   * `getReaders`: that one is an admin list behind the HID view right, and a
+   * member holding only `hid-mgmt:use-hid-access` is refused on it. This route
+   * asks for site membership and the use right. Response: `{ data: { items } }`.
+   */
+  function getEnrollmentReaders(siteId: string) {
+    return useNuxtApp().$api<{ data: { items: HidApiRecord[] } }>(
+      `${basePath}/sites/${siteId}/enrollment-readers`,
+      { method: "GET" },
+    );
+  }
+
   /**
    * The signed-in member's own QR code on one reader.
    *
@@ -398,6 +414,25 @@ export default function useHidAmico() {
   }
 
 
+  /**
+   * Put a person's STORED enrolment photo on a reader.
+   *
+   * No body: the image is the one already on file from when they were first
+   * captured. This is what makes a reader that was offline during an enrolment
+   * retryable WITHOUT the person coming back - a face template lives on one
+   * device and cannot be copied, so the alternative is a fresh capture at every
+   * reader.
+   *
+   * Keyed by the iService account, not a HID user id: the caller does not know
+   * which number the person carries on which reader, and the server looks it up.
+   */
+  function pushStoredFace(readerId: string, userId: string) {
+    return useNuxtApp().$api<{ data: HidFacialEnrollmentResult; message?: string }>(
+      `${basePath}/readers/${readerId}/accounts/${userId}/stored-face`,
+      { method: "POST" },
+    );
+  }
+
   function setUserImage(
     readerId: string,
     hidUserId: string | number,
@@ -660,6 +695,7 @@ export default function useHidAmico() {
 
   return {
     getReaders,
+    getEnrollmentReaders,
     getProfileQr,
     issueProfileQr,
     deleteProfileQr,
@@ -681,6 +717,7 @@ export default function useHidAmico() {
     reconcileReaderIdentificationMethods,
     getLogs,
     setUserImage,
+    pushStoredFace,
     deleteUserImage,
     getUserCards,
     assignUserCard,

package/composables/useHidNavigation.ts

@@ -3,23 +3,23 @@ import type { ComputedRef, Ref } from "vue";
 /**
  * THE HID FACE READER MENU IS A PERMISSION, NOT A SERVICE FLAG.
  *
- * This composable used to draw the five-item "HID Face Reader" group whenever
- * `getHidServiceEnabled(site)` was true. That is a SITE SERVICE FLAG — it says
- * the estate bought HID, not that this member may use it. Since the six
- * `access-mgmt` screens were gated (`HidEnabledGate.vue`, layer-common #1363 /
- * 4.2.14) a member without an access-card right still saw all five items and
- * only met the refusal after clicking. A module a member cannot use should not
- * be in the menu at all.
+ * This composable used to draw the six item "HID Reader" group whenever
+ * `getHidServiceEnabled(site)` was true. That is a SITE SERVICE FLAG: it says
+ * the estate bought HID, not that this member may use it. A module a member
+ * cannot use should not be in the menu at all, so the menu asks the same
+ * questions the pages ask (`useHidAccessPermission`), ANDed with the service
+ * flag: no HID service still means no menu.
  *
- * The menu now asks the SAME question the pages ask —
- * `useHidAccessPermission().canAccessHidScreens` — ANDed with the service flag,
- * so no HID service still means no menu.
+ * Decision of 2026-10-16: the admin entries (Face Reader, HID Reader Users, HID
+ * Cards, Intercom, Access Logs) follow `canViewHid`; the member's own "HID QR
+ * Code" entry follows `canUseHid`. The group is drawn when at least one entry
+ * is, so a member holding only `use-hid-access` still finds their QR page, and
+ * a member holding only the admin rights does not see a page the server would
+ * refuse them. `site-settings:manage-entry-pass` no longer draws anything here.
  *
- * `Layout/NavigationDrawer.vue` used to keep its own hand-written copy of the
- * permission list, and that copy was NARROWER than the page gate: it omitted
- * `replace-access-card` and `site-settings:manage-entry-pass`. Folding it in
- * here therefore WIDENS — nobody who could see the menu can lose it — and
- * leaves one list in one place.
+ * `Layout/NavigationDrawer.vue` keeps no permission list of its own: it takes
+ * `menuItem` from here and runs it through `withoutDeniedRoutes`, where the
+ * client's module list (`hid-mgmt`) can take the whole group away again.
  */
 
 type HidNavigationParams = {
@@ -32,14 +32,21 @@ type HidNavigationSite = Record<string, unknown>;
 export default function useHidNavigation() {
   const { getSiteById } = useSiteSettings();
   const { getHidServiceEnabled } = useOptionalServices();
-  const { canAccessHidScreens } = useHidAccessPermission();
+  const { canViewHid, canUseHid } = useHidAccessPermission();
 
+  /**
+   * The whole group, unfiltered. Exported for callers that compose their own
+   * menus; `useHidFaceReaderMenu` below is the one that applies the rights.
+   * Each entry says which right draws it so the filter cannot drift from the
+   * list.
+   */
   function getHidFaceReaderMenu({ org, site }: HidNavigationParams) {
     return {
-      title: "HID Face Reader",
+      title: "HID Reader",
       children: [
         {
           title: "Face Reader",
+          hidRight: "view" as const,
           route: {
             name: "org-site-access-mgmt-hid-readers",
             params: { org, site },
@@ -61,6 +68,7 @@ export default function useHidNavigation() {
           // `hid-users` is left in place and simply unlisted - the same state
           // `administrator` was in - so any existing link to it still resolves.
           title: "HID Reader Users",
+          hidRight: "view" as const,
           route: {
             name: "org-site-access-mgmt-administrator",
             params: { org, site },
@@ -71,6 +79,7 @@ export default function useHidNavigation() {
           // entry in this group acts on a resident or a visitor; this one has
           // no subject but the caller.
           title: "HID QR Code",
+          hidRight: "use" as const,
           route: {
             name: "org-site-access-mgmt-hid-qr-code",
             params: { org, site },
@@ -78,6 +87,7 @@ export default function useHidNavigation() {
         },
         {
           title: "HID Cards",
+          hidRight: "view" as const,
           route: {
             name: "org-site-access-mgmt-hid-cards",
             params: { org, site },
@@ -85,6 +95,7 @@ export default function useHidNavigation() {
         },
         {
           title: "Intercom",
+          hidRight: "view" as const,
           route: {
             name: "org-site-access-mgmt-intercom",
             params: { org, site },
@@ -92,6 +103,7 @@ export default function useHidNavigation() {
         },
         {
           title: "Access Logs",
+          hidRight: "view" as const,
           route: {
             name: "org-site-access-mgmt-access-logs",
             params: { org, site },
@@ -138,14 +150,23 @@ export default function useHidNavigation() {
       getHidServiceEnabled(site.value, siteDetails.value || fallbackSite?.value),
     );
 
-    // ...AND this member may open the screens behind it. `enabled` keeps its
-    // name and its meaning for callers: "should the HID menu be drawn".
-    const enabled = computed(() => serviceEnabled.value && canAccessHidScreens.value);
-
-    const menuItem = computed(() =>
-      enabled.value ? getHidFaceReaderMenu({ org: org.value, site: site.value }) : null,
+    // ...AND this member may open at least one screen behind it. `enabled`
+    // keeps its name and its meaning for callers: "should the HID menu be drawn".
+    const enabled = computed(
+      () => serviceEnabled.value && (canViewHid.value || canUseHid.value),
     );
 
+    // Only the entries this member's rights draw. The admin entries need
+    // `canViewHid`; the member's own QR page needs `canUseHid`.
+    const menuItem = computed(() => {
+      if (!enabled.value) return null;
+      const group = getHidFaceReaderMenu({ org: org.value, site: site.value });
+      const children = group.children.filter((child) =>
+        child.hidRight === "use" ? canUseHid.value : canViewHid.value,
+      );
+      return children.length ? { ...group, children } : null;
+    });
+
     return {
       enabled,
       serviceEnabled,

package/composables/useLandscapingPermission.ts

@@ -285,6 +285,17 @@ export default function useLandscapingPermission() {
         description: "Allows the user to manage site settings.",
       },
     },
+    // HID access, user side only (decision of 2026-10-16). The service apps
+    // have no HID admin screens yet, so a role here can be prepared with the
+    // one string that lets a member use their own QR code, face, PIN, card and
+    // intercom. Mirrored from core `src/utils/hid-access.util.ts`.
+    "hid-mgmt": {
+      "use-hid-access": {
+        check: true,
+        description:
+          "Allows the user to see HID Access in the app and use their own QR code, face, PIN, card and intercom at this site.",
+      },
+    },
   };
 
   return {

package/composables/useMechanicalElectricalPermission.ts

@@ -52,6 +52,11 @@ export default function useMechanicalElectricalPermission() {
     "area-mgmt": schedulePermissions["area-mgmt"],
     "unit-mgmt": schedulePermissions["unit-mgmt"],
     "site-settings": schedulePermissions["site-settings"],
+    // HID access, user side only (2026-10-19): the M&E mobile app gains the
+    // HID user side, so an M&E role must be able to hold `use-hid-access`.
+    // Taken from the cleaning catalogue like the keys above (one action, same
+    // description), so the two cannot drift. Catalogue-only: grants nothing.
+    "hid-mgmt": schedulePermissions["hid-mgmt"],
     "cleaning-schedule-mgmt": schedulePermissions["cleaning-schedule-mgmt"],
     "schedule-task-mgmt": schedulePermissions["schedule-task-mgmt"],
     "attendance-mgmt": schedulePermissions["attendance-mgmt"],

package/composables/usePestControlPermission.ts

@@ -93,6 +93,17 @@ export default function usePestControlPermission() {
         description: "Allows the user to manage and update site settings.",
       },
     },
+    // HID access, user side only (decision of 2026-10-16). The service apps
+    // have no HID admin screens yet, so a role here can be prepared with the
+    // one string that lets a member use their own QR code, face, PIN, card and
+    // intercom. Mirrored from core `src/utils/hid-access.util.ts`.
+    "hid-mgmt": {
+      "use-hid-access": {
+        check: true,
+        description:
+          "Allows the user to see HID Access in the app and use their own QR code, face, PIN, card and intercom at this site.",
+      },
+    },
     // area management permissions
     "area-mgmt": {
       "see-all-areas": {

package/composables/usePoolMaintenancePermission.ts

@@ -93,6 +93,17 @@ export default function usePoolMaintenancePermission() {
         description: "Allows the user to manage and update site settings.",
       },
     },
+    // HID access, user side only (decision of 2026-10-16). The service apps
+    // have no HID admin screens yet, so a role here can be prepared with the
+    // one string that lets a member use their own QR code, face, PIN, card and
+    // intercom. Mirrored from core `src/utils/hid-access.util.ts`.
+    "hid-mgmt": {
+      "use-hid-access": {
+        check: true,
+        description:
+          "Allows the user to see HID Access in the app and use their own QR code, face, PIN, card and intercom at this site.",
+      },
+    },
     // area management permissions
     "area-mgmt": {
       "see-all-areas": {

package/composables/usePropertyPermission.ts

@@ -14,7 +14,8 @@ import { useCommonPermissions } from "./useCommonPermission";
  * Two copies is how they drift. On 2026-09-05 the `-org` copy was found to be a
  * strict SUBSET of `-property-management`'s — **32 permissions short**, nine
  * whole families plus all six `access-card-mgmt` strings that
- * `core/utils/hid-access.util.ts` actually enforces — so a role built through
+ * `core/utils/hid-access.util.ts` enforced at the time (HID reads its own
+ * `hid-mgmt` family since 2026-10-16) — so a role built through
  * the onboarding wizard could never be granted them, and the modules were
  * unreachable for anybody who joined that way. web-app-org #189 closed it by
  * copying the file across, which left two identical copies and the same trap
@@ -256,10 +257,6 @@ export default function usePropertyPermission() {
         description:
           "Allows the user to remove an access card from the system permanently.",
       },
-      view: {
-        check: true,
-        description: "Allows the user to view an access card's details.",
-      },
       "assign-access-card": {
         check: true,
         description: "Allows the user to assign an access card to a person.",
@@ -269,10 +266,37 @@ export default function usePropertyPermission() {
         description:
           "Allows the user to replace a lost or damaged access card with a new one.",
       },
-      "manage-hid": {
+    },
+    // HID access management (decision of 2026-10-16). Five strings under one
+    // resource, mirrored from core `src/utils/hid-access.util.ts`; the HID
+    // screens, menu and buttons (`useHidAccessPermission`) and every
+    // `/api/access-management/hid` route read them. Wildcard passes all five,
+    // an empty list passes none, either manage right implies view.
+    "hid-mgmt": {
+      "use-hid-access": {
+        check: true,
+        description:
+          "Allows the user to see HID Access in the app and use their own QR code, face, PIN, card and intercom at this site.",
+      },
+      "see-all-hid": {
+        check: true,
+        description:
+          "Allows the user to view the site's HID readers, enrolled people, cards and access logs.",
+      },
+      "manage-hid-readers": {
+        check: true,
+        description:
+          "Allows the user to add, configure, test, sync and remove HID readers. Includes viewing.",
+      },
+      "manage-hid-users": {
+        check: true,
+        description:
+          "Allows the user to enrol and remove people, cards and PINs, and assign HID access groups. Includes viewing.",
+      },
+      "manage-hid-settings": {
         check: true,
         description:
-          "Allows the user to manage the HID door readers an access card opens.",
+          "Allows the user to switch HID on or off for the site and configure the HID QR code.",
       },
     },
     "service-provider-mgmt": {