@7365admin1/layer-common 4.149.1 → 4.150.0

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": {

package/composables/useSecurityPermission.ts

@@ -575,12 +575,10 @@ export default function useSecurityPermission() {
         description: "Allows the user to delete/remove a unit.",
       },
     },
-    // The strings API-core's HID routes already enforce. `authorizeView` and
-    // `authorizeManage` on every `/api/access-management/hid` route resolve to
-    // core's `utils/hid-access.util.ts` lists -- this family -- so a security
-    // agency that cannot be granted them is refused by the server on every HID
-    // call. Offering them here does not open any gate; it makes the server's
-    // existing rule grantable.
+    // Access cards. Until 2026-10 this family was also what every
+    // `/api/access-management/hid` route read; HID now has `hid-mgmt` below and
+    // the card strings here mean cards again (the server still accepts them
+    // for HID during the alias period, see `useHidAccessPermission`).
     "access-card-mgmt": {
       "see-all-card": {
         check: true,
@@ -590,11 +588,6 @@ export default function useSecurityPermission() {
         check: true,
         description: "Allows the user to view QR tagging.",
       },
-      view: {
-        check: true,
-        description:
-          "Allows the user to view access card management, including HID readers and access logs.",
-      },
       "add-access-card": {
         check: true,
         description: "Allows the user to add a new access card to the system.",
@@ -616,10 +609,37 @@ export default function useSecurityPermission() {
         check: true,
         description: "Allows the user to replace a lost or damaged access card.",
       },
-      "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 HID face readers, cards and access records for the site.",
+          "Allows the user to switch HID on or off for the site and configure the HID QR code.",
       },
     },
     // Two resources below are checked ONLY by the iSecure365 mobile app, which

package/composables/useServiceProvider.ts

@@ -19,10 +19,15 @@ export type TSiteProviderMember = {
   unit?: string | null;
   unitName?: string;
   /**
-   * The person's user account. NOT yet returned by the endpoint — the
-   * repository projects it but the service layer drops it. Anything acting on
-   * the PERSON (assigning an access card writes it onto the card as `userId`)
-   * needs this rather than `_id`, which identifies the membership.
+   * The person's user account. Anything acting on the PERSON needs this rather
+   * than `_id`, which identifies the membership: an access card carries it as
+   * `userId`, and HID reader access is bound by it -
+   * `resolvePermissionUserBindings` drops every subject without one.
+   *
+   * Returned from core 3.130. Before that the repository projected it and the
+   * service layer dropped it, so against an older API it is absent on every
+   * row - `providerAccountsKnown` is how the HID enrolment screen tells the two
+   * apart rather than reading an absence as "nobody has an account".
    */
   user?: string | null;
 };

package/constants/permissions.ts

@@ -380,16 +380,38 @@ export const PERMISSIONS = {
     "add-service-provider",
     "invite-service-provider",
   ],
+  // Access cards and QR tagging: the Property Management screens of those
+  // names. Until 2026-10 the HID screens borrowed this family (core
+  // `hid-access.util.ts` read nine of its strings); HID now has `hid-mgmt`
+  // below. `view` and `manage-hid` were only ever HID rights, so they left with
+  // it: see `RETIRED_PERMISSIONS` for how they are still read during the alias
+  // period.
   "access-card-mgmt": [
     "see-all-card",
     "see-all-qr-tagging",
-    "view",
     "add-access-card",
     "update-access-card",
     "replace-access-card",
     "delete-access-card",
     "assign-access-card",
-    "manage-hid",
+  ],
+  // HID access management (decision of 2026-10-16). The five strings are
+  // defined in core `src/utils/hid-access.util.ts` (`HID_RESOURCE` and the
+  // `HID_*_PERMISSIONS` lists); this package does not depend on `@7365admin1/core`,
+  // so it keeps its own copy and `test/hid-access-gate.test.mjs` pins the five.
+  //   use-hid-access       user side: own QR, face, PIN, card, intercom
+  //   see-all-hid          read any HID admin screen
+  //   manage-hid-readers   add, configure, test, sync, remove readers
+  //   manage-hid-users     enrol and remove people, cards, PINs, groups
+  //   manage-hid-settings  HID on or off and the QR configuration for a site
+  // Wildcard passes all five; an empty list passes none; either manage right
+  // implies view. The module deny list key is the resource name.
+  "hid-mgmt": [
+    "use-hid-access",
+    "see-all-hid",
+    "manage-hid-readers",
+    "manage-hid-users",
+    "manage-hid-settings",
   ],
 
   // ---- security ----
@@ -659,12 +681,14 @@ export const LEGACY_PERMISSION_ALIASES: Readonly<
 /**
  * Strings the SERVER enforces that no UI checks and no role editor can grant.
  *
- * `core/src/utils/hid-access.util.ts:36-38` gates the HID Amico visitor
- * endpoints on `visitor:create`, `visitor:update` and `visitor:check-out`. The
- * whole estate spells visitor rights `visitor-mgmt:add-visitor`,
- * `:update-visitor` and so on; a bare `visitor` resource appears in no catalogue
- * in any repo, so no role can hold these and the branch is reachable only
- * through `*` or through the `access-card-mgmt` strings the same list unions in.
+ * `core/src/utils/hid-access.util.ts` keeps `visitor:create`, `visitor:update`
+ * and `visitor:check-out` in `HID_VISITOR_PERMISSIONS` (the visitor pass revoke
+ * routes) until the alias drop. The whole estate spells visitor rights
+ * `visitor-mgmt:add-visitor`, `:update-visitor` and so on; a bare `visitor`
+ * resource appears in no catalogue in any repo, so no role can hold these and
+ * the branch is reachable only through `*`, through
+ * `visitor-mgmt:update-visitor` (which the same list now also accepts) or
+ * through the HID manage users strings it unions in.
  *
  * They are NOT aliased to `visitor-mgmt:*` here, because doing so would be a
  * decision with a real consequence in both directions:
@@ -695,19 +719,47 @@ export const SERVER_ONLY_UNGRANTABLE: readonly string[] = Object.freeze([
  * Canonical strings that are CHECKED -- by this package and by the server -- and
  * that no role editor can GRANT.
  *
- * `NavigationDrawer.vue:172-180` accepts eight `access-card-mgmt` strings for
- * the HID menu and `core/src/utils/hid-access.util.ts:19-32` enforces all nine;
- * only six of them appear in any app's catalogue. The menu still opens, because
- * the gate is an OR and the other six are grantable -- but a role built out of
- * only these three is refused at both ends while looking correctly configured in
- * the role editor. Frozen here so the list cannot grow without somebody noticing.
+ * Empty since 2026-10-16. It used to hold `access-card-mgmt:view`,
+ * `:assign-access-card` and `:manage-hid`, which the HID menu accepted and
+ * `core/src/utils/hid-access.util.ts` enforced while no app's catalogue offered
+ * them. HID now has its own `hid-mgmt` family, offered in full by the property
+ * and security catalogues and as `use-hid-access` by the five service
+ * catalogues (M&E joined on 2026-10-19); `assign-access-card` is offered by
+ * both card catalogues; `view` and `manage-hid` are retired (below). Kept,
+ * and still pinned by the drift test, so the next string of this shape is
+ * recorded here rather than found by somebody staring at a blank screen.
  */
 export const CHECKED_BUT_UNGRANTABLE: readonly TPermissionString[] =
-  Object.freeze([
-    "access-card-mgmt:view",
-    "access-card-mgmt:assign-access-card",
-    "access-card-mgmt:manage-hid",
-  ]);
+  Object.freeze([]);
+
+/**
+ * Strings that are no longer canonical and have no canonical equivalent, but
+ * that this package and the server STILL READ for one release.
+ *
+ * `access-card-mgmt:view` and `access-card-mgmt:manage-hid` were the HID
+ * rights before `hid-mgmt` existed. Core `hid-access.util.ts` keeps them in
+ * `HID_LEGACY_VIEW_PERMISSIONS` and `HID_LEGACY_MANAGE_PERMISSIONS` until the
+ * live roles are backfilled onto the five `hid-mgmt` strings, and
+ * `useHidAccessPermission` reads them at the same levels during that period.
+ * No role editor offers them any more, and nothing new may be written against
+ * them.
+ *
+ * They are NOT legacy aliases: an alias joins two spellings of ONE grant into
+ * an equivalence class (`utils/permission-spellings.ts`) and joins the two
+ * resources into one module spelling group (`utils/org-modules.ts`). Access
+ * cards and HID are two modules, and `manage-hid` meant three HID levels at
+ * once, so neither of those is true here.
+ *
+ * `isKnownPermission` answers true for these; `canonicalPermission` does not
+ * resolve them. The alias drop deletes this list and the composable's legacy
+ * branches together.
+ */
+export const RETIRED_PERMISSIONS: Readonly<Record<string, string>> = Object.freeze({
+  "access-card-mgmt:view":
+    "HID view right before hid-mgmt:see-all-hid; read until the alias drop",
+  "access-card-mgmt:manage-hid":
+    "HID manage right before hid-mgmt:manage-hid-*; read until the alias drop",
+});
 
 const CANONICAL = new Set<string>(PERMISSION_STRINGS);
 
@@ -724,7 +776,7 @@ export function canonicalPermission(
   return LEGACY_PERMISSION_ALIASES[value];
 }
 
-/** Is this string one the catalogue knows, canonical or legacy? */
+/** Is this string one the catalogue knows: canonical, legacy, or retired but still read? */
 export function isKnownPermission(value: string): boolean {
-  return canonicalPermission(value) !== undefined;
+  return canonicalPermission(value) !== undefined || value in RETIRED_PERMISSIONS;
 }

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.149.1",
+  "version": "4.150.0",
   "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.",

package/pages/[org]/[site]/access-mgmt/hid-qr-code/index.vue

@@ -1,8 +1,11 @@
 <template>
   <v-container fluid>
+    <!-- The member's own pass, so the gate asks for the use right, not the
+         admin view right every other HID page asks for. -->
     <HidEnabledGate
       :site="siteId"
       :org="orgId"
+      level="use"
       message="Enable HID as a service for this site before generating a QR code."
     >
       <HidProfileQrCode :site="siteId" />

package/types/overnight-parking.d.ts

@@ -14,6 +14,20 @@ declare type TOvernightParkingAvailability = {
   sunday: TOvernightParkingDay;
   isAllowPlateNumberOpenBarrier?: boolean;
   autoApproveOvernightParking?: boolean;
+  visitorQrCodes?: TVisitorQrCode[];
+};
+
+declare type TVisitorQrCodeType = "hid" | "entryPass" | "security";
+
+// How long an HID visitor pass lasts: until the end of the visit day, or
+// until the visitor's first entry.
+declare type TVisitorQrUsage = "wholeDay" | "singleUse";
+
+declare type TVisitorQrCode = {
+  type: TVisitorQrCodeType;
+  isEnabled: boolean;
+  // HID only.
+  usage?: TVisitorQrUsage;
 };
 
 declare type TOvernightParkingRequestStatus =

package/types/site.d.ts

@@ -5,7 +5,10 @@ declare type THidQrCodeFormat = "0" | "1" | "2";
 declare type THidPermissionCategory =
   | "resident"
   | "property_management"
-  | "service_provider";
+  /** A provider COMPANY - granting one admits every active member of that org. */
+  | "service_provider"
+  /** ONE PERSON from a provider company, by their membership at this site. */
+  | "service_provider_member";
 
 declare type THidPermissionAssignment = {
   subjectId: string;
@@ -27,7 +30,10 @@ declare type THidSitePermissions = {
   counts: {
     resident: number;
     propertyManagement: number;
+    /** Provider COMPANIES granted. */
     serviceProvider: number;
+    /** Named provider people granted. Counted apart from the companies. */
+    serviceProviderMember: number;
     intercom: number;
   };
 };