@7365admin1/layer-common 4.1.0 → 4.1.2-staging.244

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # @iservice365/layer-common
 
+## 4.1.1
+
+### Patch Changes
+
+- df2fede: Fix the Service Providers gate: check the permission the estate actually stores
+
+  `useServiceProviderPermission` shipped in 4.0.3 asking for
+  `service-provider:<action>`. Measured read-only against the staging `roles`
+  collection on 2026-08-26, that spelling is held by **0 of 428 roles**, while
+  `service-provider-mgmt:add-service-provider`, `:invite-service-provider` and
+  `:view-service-providers` are held by **79 roles each**. Every role except the 71
+  holding `*` was refused, on any consumer that does not bind the three props.
+
+  The gate now checks `service-provider-mgmt` -- the canonical resource in
+  `constants/permissions.ts`, the one the server reads in
+  `notification-category.util.ts`, and the one `-property-management`'s own
+  `useLocalPermission` has always checked. The view gate accepts both
+  `view-service-providers` (what the 79 roles store today) and
+  `see-all-service-providers` (canonical), so no role migration is needed for this
+  fix to work and none is invalidated later.
+
+  No permission key is renamed or invented, and no role document changes.
+
 ## 4.1.0
 
 ### Minor Changes
@@ -290,11 +313,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/composables/useServiceProviderPermission.ts

@@ -3,26 +3,52 @@ import { useCommonPermissions } from "./useCommonPermission";
 export function useServiceProviderPermission() {
   const { hasPermission } = usePermission();
   const { serviceProviderPermissions } = useCommonPermissions();
-  const permissions: TPermissions = { "service-provider": serviceProviderPermissions };
+
+  // The resource the estate actually stores. `constants/permissions.ts` settles
+  // `service-provider-mgmt` as canonical on rule 1 -- the server reads it at
+  // `core/utils/notification-category.util.ts:185` -- and it is what
+  // `-property-management`'s own `useLocalPermission` has always checked.
+  //
+  // This gate shipped asking for `service-provider:<action>` instead, a spelling
+  // that exists in no role document: on the staging role catalogue (428 roles)
+  // it is held by 0, so every role except the 71 holding `*` was refused. The
+  // strings below are held by 79 roles each.
+  const permissions: TPermissions = {
+    "service-provider-mgmt": {
+      ...serviceProviderPermissions,
+      // `view-service-providers` is the spelling all 79 roles were granted;
+      // `see-all-service-providers` is canonical and nobody holds it yet. Both
+      // are accepted, so the gate is correct before AND after a role migration
+      // -- switching to the canonical string alone is what left pest-control's
+      // work-order gate stranding 92 roles. Recorded in
+      // `LEGACY_PERMISSION_ALIASES`.
+      "view-service-providers": serviceProviderPermissions["see-all-service-providers"],
+    },
+  };
 
   const { userAppRole } = useLocalSetup();
 
+  // Every gate fails closed while the role is still resolving: `userAppRole` is
+  // null on the first tick and a null role must never read as "allowed".
   const canAddServiceProvider = computed(() => {
     if (!userAppRole.value) return false;
     if (userAppRole.value.permissions.includes("*")) return true;
-    return hasPermission(userAppRole.value, permissions, "service-provider", "add-service-provider");
+    return hasPermission(userAppRole.value, permissions, "service-provider-mgmt", "add-service-provider");
   });
 
   const canInviteServiceProvider = computed(() => {
     if (!userAppRole.value) return false;
     if (userAppRole.value.permissions.includes("*")) return true;
-    return hasPermission(userAppRole.value, permissions, "service-provider", "invite-service-provider");
+    return hasPermission(userAppRole.value, permissions, "service-provider-mgmt", "invite-service-provider");
   });
 
   const canViewServiceProviders = computed(() => {
     if (!userAppRole.value) return false;
     if (userAppRole.value.permissions.includes("*")) return true;
-    return hasPermission(userAppRole.value, permissions, "service-provider", "see-all-service-providers");
+    return (
+      hasPermission(userAppRole.value, permissions, "service-provider-mgmt", "see-all-service-providers") ||
+      hasPermission(userAppRole.value, permissions, "service-provider-mgmt", "view-service-providers")
+    );
   });
 
   return {

package/constants/permissions.ts

@@ -592,16 +592,21 @@ export const LEGACY_PERMISSION_ALIASES: Readonly<
   "roles-and-permissions:delete-role": "roles:delete-role",
 
   // --- service providers ---
-  // Needed by: `useServiceProviderPermission` in this package, which drops the
-  // `-mgmt` the server's notification filter expects.
+  // Needed by: layer-common 4.0.3 and 4.1.0, where `useServiceProviderPermission`
+  // dropped the `-mgmt` the server's notification filter expects and asked for a
+  // resource 0 of 428 roles hold. The composable checks `service-provider-mgmt`
+  // from 4.1.1 on; these three stay because both published versions are still
+  // installed across the estate.
   "service-provider:see-all-service-providers":
     "service-provider-mgmt:see-all-service-providers",
   "service-provider:add-service-provider":
     "service-provider-mgmt:add-service-provider",
   "service-provider:invite-service-provider":
     "service-provider-mgmt:invite-service-provider",
-  // Needed by: `-property-management`, which says `view-` where this layer says
-  // `see-all-`.
+  // Needed by: `-property-management` AND `useServiceProviderPermission` in this
+  // package, which both say `view-` where the canonical spelling says `see-all-`.
+  // This is the spelling all 79 granted roles actually store, so it cannot be
+  // retired until those roles are migrated.
   "service-provider-mgmt:view-service-providers":
     "service-provider-mgmt:see-all-service-providers",
 });

package/package.json

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