@7365admin1/layer-common 4.2.12 → 4.2.14

package/CHANGELOG.md

@@ -1,5 +1,36 @@
 # @iservice365/layer-common
 
+## 4.2.14
+
+### Patch Changes
+
+- 1d22a74: Gate the six HID access-mgmt screens on the access-card-mgmt permissions the API already enforces
+
+  The access-logs, administrator, hid-cards, hid-readers, hid-users and intercom
+  pages carried no permission check, so any member of any organisation could type
+  the URL and reach door access, biometric enrolment, physical cards and the
+  access log. HidEnabledGate now also requires the caller to hold one of the nine
+  access-card-mgmt strings, site-settings:manage-entry-pass, or the wildcard.
+
+  Those are the same strings /api/access-management/hid already enforces, so the
+  set now refused is a strict subset of the set the API refuses today: nobody with
+  a working screen loses it.
+
+## 4.2.13
+
+### Patch Changes
+
+- 396bae2: Accept every shipped spelling of a permission when deciding a gate.
+
+  `hasPermission` tested one exact string, so a role holding a minority spelling
+  (`work-orders:see-all-work-orders`, `feedbacks:see-all-feedbacks`,
+  `visitor-mgmt:see-all-visitor`) was refused while the role editor showed the
+  grant. camelCase stays canonical and the role editor is unchanged; nothing
+  stored is rewritten. Widening only.
+
+  The role editor's ticks and its read-only preview are alias-aware too, so a
+  grant stored under an alias is shown and can actually be cleared.
+
 ## 4.2.12
 
 ### Patch Changes
@@ -580,11 +611,11 @@
   `utils/console-tier.ts` + `composables/useConsoleTier.ts` mirror the server's
   own rule from two endpoints the console already calls, unprojected:
 
-                                        GET /api/members/user/:user/app/admin    the Seven365 staff membership
-                                        GET /api/roles/id/:role                  that membership's role document
+                                            GET /api/members/user/:user/app/admin    the Seven365 staff membership
+                                            GET /api/roles/id/:role                  that membership's role document
 
-                                        owner  = member.type === "admin" && role.type === "admin" && role.default === true
-                                        staff  = member.type === "admin" && role.type === "admin"
+                                            owner  = member.type === "admin" && role.type === "admin" && role.default === true
+                                            staff  = member.type === "admin" && role.type === "admin"
 
   `role.default` is the marker because it is the only property of a platform
   staff role no API caller can set - `role.controller.ts` validates create and

package/components/HidEnabledGate.vue

@@ -17,7 +17,22 @@
   a coloured slab. Icons are translated centrally — no hand-mapping here.
 -->
 <template>
-  <slot v-if="hidEnabled" />
+  <!-- Nothing at all while the role is still resolving. `userAppRole` is null
+       on the first tick for EVERYONE including the `*` owner, so drawing the
+       denial here would flash "no permission" at the owner on every load. -->
+  <template v-if="!isAppRoleResolved" />
+
+  <slot v-else-if="hidEnabled && canAccessHidScreens" />
+
+  <div v-else-if="hidEnabled" class="screen-empty hid-gate">
+    <span class="hid-gate__icon tone-info">
+      <v-icon icon="mdi-lock-outline" size="24" />
+    </span>
+    <h2 class="hid-gate__title">You do not have permission for HID access management</h2>
+    <p class="hid-gate__body">
+      Ask an administrator to grant your role access card management for this site.
+    </p>
+  </div>
 
   <div v-else class="screen-empty hid-gate">
     <span class="hid-gate__icon tone-info">
@@ -45,6 +60,14 @@ const props = withDefaults(
 const { getSiteById } = useSiteSettings();
 const { getHidServiceEnabled } = useOptionalServices();
 
+// The permission half of the same gate. This component is the only thing all
+// six `access-mgmt` pages have in common, so putting the check here governs all
+// six -- and all 66 inherited routes across the eleven apps -- without a page
+// guard per screen. See `composables/useHidAccessPermission.ts` for why the
+// gate cannot remove access that currently works.
+const { canAccessHidScreens } = useHidAccessPermission();
+const { isAppRoleResolved } = useLocalSetup();
+
 // Do not await this request during route setup. Every HID page uses this gate;
 // awaiting it makes Nuxt Suspense keep rendering the previous page until the
 // site request finishes, so the URL changes while the visible module appears

package/components/RolePermissionFormPreviewUpdate.vue

@@ -66,8 +66,9 @@
                       <template #prepend>
                         <v-checkbox-btn
                           :model-value="
-                            definedModel.includes(
-                              `${String(resourceKey)}:${String(actionKey)}`
+                            isActionSelected(
+                              String(resourceKey),
+                              String(actionKey)
                             )
                           "
                           :disabled="!edit"
@@ -130,6 +131,10 @@
 <script setup lang="ts">
 import useRole from "../composables/useRole";
 import useUtils from "../composables/useUtils";
+import {
+  holdsPermission,
+  withoutPermission,
+} from "../utils/permission-spellings";
 
 const definedModel = defineModel<Array<string>>({
   default: () => [],
@@ -185,7 +190,26 @@ function isWebOnly(resource: string) {
   return props.webOnlyResources.includes(resource);
 }
 
+/**
+ * Is this box ticked?
+ *
+ * The same grant is stored under more than one spelling. An exact `includes()`
+ * showed a role holding `work-orders:see-all-work-orders` as NOT having
+ * `workOrder:see-all-work-orders`, so the dialog reported a grant the role
+ * really holds as absent -- and unticking a box then cleared nothing. Ticks are
+ * alias-aware, and so is the untick below.
+ */
+function isActionSelected(resource: string, action: string) {
+  return holdsPermission(definedModel.value, `${resource}:${action}`);
+}
+
 function selectedActionCount(resource: string) {
+  const actions = safePermissions.value[resource];
+  if (actions) {
+    return Object.keys(actions).filter((action) =>
+      isActionSelected(resource, action)
+    ).length;
+  }
   return definedModel.value.filter((permission) =>
     permission.startsWith(`${resource}:`)
   ).length;
@@ -208,20 +232,22 @@ function toggleCategory(resource: string, value: boolean | null) {
   expandedResources.value = expandedResources.value.filter(
     (item) => item !== resource
   );
-  definedModel.value = definedModel.value.filter(
-    (permission) => !permission.startsWith(`${resource}:`)
+  const actions = Object.keys(safePermissions.value[resource] ?? {});
+  definedModel.value = actions.reduce(
+    (kept, action) => withoutPermission(kept, `${resource}:${action}`),
+    definedModel.value.filter(
+      (permission) => !permission.startsWith(`${resource}:`)
+    )
   );
 }
 
 function toggleAction(resource: string, action: string, value: boolean | null) {
   if (!edit.value || value === null) return;
   const permission = `${resource}:${action}`;
-  if (value && !definedModel.value.includes(permission)) {
+  if (value && !isActionSelected(resource, action)) {
     definedModel.value = [...definedModel.value, permission];
   } else if (!value) {
-    definedModel.value = definedModel.value.filter(
-      (item) => item !== permission
-    );
+    definedModel.value = withoutPermission(definedModel.value, permission);
   }
 }
 
@@ -233,7 +259,8 @@ const isAllSelected = computed(() => {
       Object.keys(actions || {}).map((action) => `${resource}:${action}`)
   );
   return (
-    keys.length > 0 && keys.every((key) => definedModel.value.includes(key))
+    keys.length > 0 &&
+    keys.every((key) => holdsPermission(definedModel.value, key))
   );
 });
 

package/components/RolePermissionMain.vue

@@ -189,6 +189,7 @@
 <script setup lang="ts">
 // Relative import: this layer's `utils/` is not auto-imported into consumers.
 import { showSiteField } from "../utils/role";
+import { holdsPermission } from "../utils/permission-spellings";
 
 const props = defineProps({
   orgId: {
@@ -414,7 +415,12 @@ function filterPermissions(
   Object.entries(allPermissions).forEach(([resource, actions]) => {
     if (!actions || typeof actions !== "object") return;
     const filteredActions = Object.entries(actions)
-      .filter(([action]) => storedPermissions.includes(`${resource}:${action}`))
+      // Alias-aware: the read-only preview must list a grant the role holds
+      // under any shipped spelling, or the same string is invisible here and
+      // ticked in the editor.
+      .filter(([action]) =>
+        holdsPermission(storedPermissions, `${resource}:${action}`)
+      )
       .reduce((acc: Record<string, any>, [action, data]) => {
         acc[action] = data;
         return acc;

package/composables/useHidAccessPermission.ts

@@ -0,0 +1,115 @@
+/**
+ * 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.
+ *
+ * ## Why adding this gate cannot lock anybody out
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * `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.
+ *
+ * ## Intercom is gated with the other five
+ *
+ * `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.
+ *
+ * ## 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 nine strings `core/utils/hid-access.util.ts` enforces, view + manage. */
+const HID_ACTIONS = [
+  "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",
+] as const;
+
+export function useHidAccessPermission() {
+  const { hasPermission } = usePermission();
+  const { siteSettingsPermissions } = useCommonPermissions();
+  const { userAppRole } = 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.
+  const permissions: TPermissions = {
+    "access-card-mgmt": Object.fromEntries(
+      HID_ACTIONS.map((action) => [
+        action,
+        {
+          check: true,
+          description: `Allows the user to reach the HID access management screens (${action}).`,
+        },
+      ]),
+    ),
+    "site-settings": siteSettingsPermissions,
+  };
+
+  /**
+   * 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.
+   */
+  const canAccessHidScreens = computed(() => {
+    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 };
+}
+
+export default useHidAccessPermission;

package/composables/usePermission.ts

@@ -1,3 +1,5 @@
+import { holdsPermission } from "../utils/permission-spellings";
+
 export default function usePermission() {
   // Permission-Based Access Control with Dynamic Role Creation
 
@@ -25,8 +27,16 @@ export default function usePermission() {
   ): boolean {
     const permissionKey = `${resource}:${action}`;
 
-    // Check if the permission exists in the user's permission array
-    if (!user.permissions?.includes(permissionKey)) {
+    // Check if the permission exists in the user's permission array.
+    //
+    // The same grant is stored under more than one spelling -- the role editor
+    // writes `workOrder:see-all-work-orders` (81 roles) but a minority of roles
+    // hold `work-orders:see-all-work-orders` (6). An exact test answered "no"
+    // for those roles while the console showed the grant. `holdsPermission`
+    // accepts any shipped spelling of the same grant; camelCase stays canonical
+    // and nothing stored is rewritten. Widening only -- no role that passed
+    // before can fail now.
+    if (!holdsPermission(user.permissions, permissionKey)) {
       return false;
     }
 

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.2.12",
+  "version": "4.2.14",
   "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/utils/permission-spellings.ts

@@ -0,0 +1,87 @@
+import {
+  LEGACY_PERMISSION_ALIASES,
+  PERMISSION_STRINGS,
+} from "../constants/permissions.ts";
+
+/**
+ * The same grant is stored under more than one spelling.
+ *
+ * `constants/permissions.ts` already records every shipped spelling as
+ * `legacy -> canonical`. That map was written for the drift test; this file is
+ * the ENFORCEMENT side of it. It turns the one-way map into equivalence
+ * classes, so a check for one spelling is answered by any spelling of the same
+ * grant.
+ *
+ * Which spelling is CANONICAL is settled and unchanged by this file: the role
+ * editor keeps writing what it has always written (`workOrder:…`,
+ * `feedbacks:see-all-feedback`, `visitorManagement:…`), which is the majority
+ * spelling in live role data by an order of magnitude (81 roles vs 6, 95 vs 8).
+ * Nothing stored is rewritten. This is a WIDENING only: a role that passed a
+ * gate before still passes it, and a role holding a minority spelling stops
+ * being silently unenforced.
+ */
+/**
+ * Spellings that are recorded in the alias map but must NOT be accepted.
+ *
+ * `service-provider:*` (no `-mgmt`) is the 4.0.3 regression: 0 of 428 roles
+ * hold it, and `test/service-provider-gate.test.mjs` pins it shut so nobody
+ * reintroduces a gate that reads a string which can never arrive. Accepting it
+ * would grant nobody anything and would quietly remove that tripwire. The map
+ * keeps the entry because the drift test needs to know the string exists.
+ */
+const NOT_ACCEPTED: ReadonlySet<string> = new Set([
+  "service-provider:see-all-service-providers",
+  "service-provider:add-service-provider",
+  "service-provider:invite-service-provider",
+]);
+
+const SPELLINGS: ReadonlyMap<string, readonly string[]> = (() => {
+  const classes = new Map<string, Set<string>>();
+  const join = (canonical: string, spelling: string) => {
+    const members = classes.get(canonical) ?? new Set<string>([canonical]);
+    members.add(spelling);
+    classes.set(canonical, members);
+  };
+
+  for (const canonical of PERMISSION_STRINGS) join(canonical, canonical);
+  for (const [legacy, canonical] of Object.entries(LEGACY_PERMISSION_ALIASES)) {
+    if (NOT_ACCEPTED.has(legacy)) continue;
+    join(canonical, legacy);
+  }
+
+  const bySpelling = new Map<string, readonly string[]>();
+  for (const members of classes.values()) {
+    const all = Object.freeze([...members]);
+    for (const spelling of all) bySpelling.set(spelling, all);
+  }
+  return bySpelling;
+})();
+
+/** Every shipped spelling of the same grant, `value` included. */
+export function permissionSpellings(value: string): readonly string[] {
+  return SPELLINGS.get(value) ?? [value];
+}
+
+/** Does this stored permission list carry `value` under ANY shipped spelling? */
+export function holdsPermission(
+  held: readonly string[] | undefined | null,
+  value: string,
+): boolean {
+  if (!held?.length) return false;
+  return permissionSpellings(value).some((spelling) => held.includes(spelling));
+}
+
+/**
+ * Drop `value` under EVERY spelling.
+ *
+ * The counterpart to `holdsPermission`. A tick that is alias-aware must have an
+ * untick that is too, or clearing the box leaves the grant in place and the
+ * screen lies in the other direction.
+ */
+export function withoutPermission(
+  held: readonly string[],
+  value: string,
+): string[] {
+  const spellings = permissionSpellings(value);
+  return held.filter((item) => !spellings.includes(item));
+}