@7365admin1/layer-common 4.0.3-staging.235 → 4.0.3

package/CHANGELOG.md

@@ -1,5 +1,268 @@
 # @iservice365/layer-common
 
+## 4.0.3
+
+### Patch Changes
+
+- 02e84c5: Default AccessCardPreviewDialog's Update, Replace and Delete gates to refused
+
+  The three remaining fail-open prop defaults in this package. They qualified for
+  the sweep in #1277 but sat inside #1276's own diff hunk, so they were deliberately
+  deferred until #1276 landed. It has, so they are flipped now.
+
+  `canUpdate`, `canReplaceAccessCard` and `canDeleteAccessCard` declared
+  `default: true`, so a caller that omitted one was handed the Update, Replace or
+  Delete control by the shared layer itself.
+
+  `AccessManagement` is the only caller anywhere — the layer and all eleven web
+  apps at `origin/staging` — and it binds all three to its own props, each of which
+  is declared with an explicit `default: false`. The bound expressions therefore
+  always resolve to a defined value, so the child default never fires and **no user
+  loses access**. This closes the trap for the next caller.
+
+  The contract in `test/gate-defaults.test.mjs` now covers 54 props across 22
+  components, up from 51 across 21.
+
+- 6ba8bba: BulletinBoardManagement now derives canViewBulletinBoardDetails from its own permission gate when the caller omits it
+
+  `canViewBulletinBoardDetails` declared `default: true`. Six of the seven apps
+  that render this component (`-hygiene`, `-landscape`, `-mechanical-electrical`,
+  `-pest-control`, `-pool-mgmt`, `-security`) never bind it, so every user in
+  those apps could open the bulletin-board details/edit dialog regardless of
+  permission. `useBulletinBoardPermission().canViewBulletinBoardDetails` already
+  computed this gate correctly and failed closed -- it just was never called by
+  the component.
+
+  The component now reads that composable itself as the fallback when the prop
+  is unbound (`props.canViewBulletinBoardDetails ?? derived.value`). An app that
+  already passes the prop explicitly (`-property-management`) is unaffected --
+  its value still wins. This closes the gap in-package; no app-side PR needed
+  for this one prop.
+
+- 3ac2550: Stop the still-frame refusal from blacking out the Virtual Patrol camera wall
+
+  On production every tile on the CCTV wall drew "Not set up yet" with "No recorder
+  is configured for this camera's relay.", while staging — the same build — played
+  live pictures. The difference was a recorder entry on the API host, and the live
+  picture never touches a recorder: `CameraWallTile.vue` embeds `camera.host`, the
+  relay's own player page, browser to relay, with no Seven365 server in the path.
+
+  `tileView` returned the dead tile on `camera.unavailableReason` before it ever
+  consulted `capabilities.liveVideo`. `unavailableReason` is the server's
+  **still-frame** refusal (`snapshotRefusalReason`), which genuinely does need a
+  recorder; live video does not. So a picture that was available the whole time was
+  never asked for.
+
+  The `liveVideo` capability is now read first, and the refusal only kills the tile
+  when the server has not said live video is supported. A camera that genuinely
+  cannot show anything — `unsupported`, or a server that never declared the
+  capability at all — still renders the honest "Not set up yet" tile with the
+  server's own sentence, unchanged.
+
+  When a tile draws past an outstanding still-frame refusal it carries
+  `RELAY_ONLY_NOTE` on its note, so a moving picture above a "Recorder not checked"
+  recorder line reads as two separate facts rather than a contradiction. The note
+  is used rather than `detail` because `detail` is drawn across the whole tile and
+  would cover the picture it is explaining.
+
+- 6f9a69d: Make the dashboard's work-order and visitor widgets honour the spelling each app actually grants, and fail closed before the role loads
+
+  The three apps that render `DashboardMain` spell their resources differently:
+  work orders are `work_orders` in `-security`, `workOrder` in
+  `-property-management` and `work_order` in this layer's `useCleaningPermission`;
+  visitors are `visitor-mgmt` in `-security` and `visitorManagement` in
+  `-property-management`. The widget map asked for one spelling apiece, so a
+  property-management role granted "see all work orders" and "see all visitors"
+  through its own role editor got neither widget. Every spelling in use is now
+  listed, the same defensive union the feedback and incident widgets already had.
+
+  `canViewWidget` also returned `true` when no role was loaded, so the dashboard
+  drew every widget and then removed some -- and a failed role fetch left them all
+  drawn. It now returns `false`, matching every other gate in the package.
+
+- 0ac386f: Forward two permission gates that were declared, passed by the apps, and then dropped
+
+  `BuildingManagement/units` declares `canUpdateUnit` and `canDeleteUnit`, and both
+  `-property-management` and `-security` bind them — but the component never handed
+  them to `BuildingUnitFormEdit`, which draws the Update and Delete items. That child
+  defaulted both to `true`, so a role denied update-unit or delete-unit still got both
+  actions inside the unit preview dialog.
+
+  `AccessManagement` never passed `can-assign-to-person` to `AccessCardPreviewDialog`,
+  which gates the Assign control and also defaulted to `true`. The list view in the
+  same file gates its own Assign on `canUpdateAccessCard && canAssignAccessCard`, so
+  the dialog was strictly looser than the list beside it. It now applies the same rule.
+
+  The three child defaults are flipped from `true` to `false` so a caller that forgets
+  the prop is refused rather than granted.
+
+  User-visible effect, and this one takes access away: in `-property-management` and
+  `-security`, a role without update-unit or delete-unit no longer sees Update or
+  Delete in the unit preview dialog, and a role without update-access-card or
+  assign-access-card no longer sees Assign in the card preview dialog. Those controls
+  were never meant to be there. Roles that hold the permissions are unchanged.
+
+- b4e5dd5: Default every permission-shaped prop to refused instead of allowed
+
+  51 gate-shaped props across 21 shared components declared `default: true`. A
+  permission prop that defaults open means the shared layer answers "yes" on an
+  app's behalf whenever that app forgets to bind it — the same fail-open class
+  found in `web-app-org` and in the 25 `web-app-hygiene` gates, expressed as a
+  prop default instead of `if (!userAppRole.value) return true`.
+
+  All 51 are flipped to `default: false`. Every one was first confirmed bound at
+  every existing call site — all eleven web apps read at `origin/staging`, plus
+  every layer-internal parent — and the bound expression confirmed to resolve on
+  that page, because Vue falls back to the default when a bound value is
+  `undefined`. 154 bindings checked, none unresolved.
+
+  **No user loses access from this change.** Every current call site passes an
+  explicit value, so the default never fires today; the flip closes the trap for
+  the next caller. Props that some app does not bind are deliberately left open —
+  flipping those would take a control away from a real user — and are listed in
+  the PR as cross-repo follow-ups.
+
+  The package's 66 runtime permission gates across its 10 permission composables
+  were audited in the same sweep and already fail closed; a regression test now
+  drives all of them with real non-wildcard role documents to keep it that way.
+
+- 050df56: Show the Members row menu when the only permission granted is Assign Role
+
+  The menu's `v-if` tested suspend, activate and delete only, while the Assign
+  Role item inside it tested `assignRole`. A role granted
+  `members:assign-member-role` and nothing else therefore got no row menu at all:
+  the permission was granted, the item existed, and there was no way to reach it.
+  The menu now opens for `assignRole` as well, and still fails closed when none of
+  the four is granted.
+
+- f7cafee: Stop shipping this layer's own unit-test files in the published package. The
+  `files` list included `utils` wholesale, so seventeen `utils/*.test.ts` files
+  went out in every tarball. Consuming applications scan the installed layer's
+  `utils` folder for route references, and the fixture strings inside
+  `utils/breadcrumb.test.ts` were being read as ten real route names that no page
+  produces. Excluding `**/*.test.ts` removes the false readings and drops the
+  fixtures from what every application downloads. No runtime code changes.
+- 4f69c0e: Add the missing `site-settings` and `toilet_locations` families to the cleaning permission catalogue
+
+  `useCleaningPermission()`'s catalogue had no `site-settings` key and no
+  `toilet_locations` key at all. `hasPermission` resolves an action as
+  `catalogue[resource][action]`, so both families answered `false` for every role
+  that did not hold `"*"` — on the published `4.0.1` and on `@staging` alike. This
+  is the same class as the earlier flat-catalogue fix but a different root cause:
+  the resource was missing rather than wrongly shaped, so that fix did not cover it.
+
+  Action names and nesting are copied from the sibling module catalogues that
+  already work — `usePoolMaintenancePermission` and `useLandscapingPermission` both
+  spell site settings exactly this way.
+
+  User-visible effect: in `web-app-hygiene`, a role granted "view site settings" or
+  "manage site settings" now actually reaches the Site Settings screen, and
+  "create toilet location" is grantable instead of permanently refused. Nobody
+  loses access — a full-access role behaved correctly before and is unchanged, and
+  a role that was never granted the permission is still refused.
+
+- a9bd126: Fix site-settings and bulletin-board permission gates, which only ever opened for a full-access role
+
+  `useSettingsPermission` and `useBulletinBoardPermission` passed `hasPermission` a
+  flat `{action: ...}` map where it looks the action up as `catalogue[resource][action]`.
+  `catalogue["site-settings"]` was therefore `undefined` and all eleven site-settings
+  gates plus all five bulletin-board gates answered `false` for every role — the only
+  way through was the `"*"` short-circuit. Both now wrap the group under its resource
+  key, matching the nine composables that were already nested and working.
+
+  User-visible effect: ticking a site-settings or bulletin-board box in the role
+  editor now actually shows the matching panel or control. Previously the Site
+  Settings screen came up with only the one ungated panel no matter what was granted.
+
+- 7574d24: Keep the Edit/Create Plan dialog's Cancel and Save buttons on screen
+- 51aac24: Remove seven unread gate-shaped props left over from the fail-open sweep
+
+  While auditing the 26 remaining `default: true` gate props tracked after #1276/#1277/#1278,
+  seven were found declared but never read anywhere in their own component — no template
+  binding, no `v-if`, no computed, no method body, no forwarding:
+
+  - `AccessManagement.vue`: `canUpdate`, `canDelete`
+  - `BuildingManagement/buildings.vue`: `canDelete`
+  - `BuildingManagement/units.vue`: `canUpdate`, `canDelete`
+  - `DocumentManagement.vue`: `canUpdate`, `canDelete`
+
+  Each of these four components separately declares specific, actually-used gates for the
+  same actions (e.g. `canUpdateBuilding` / `canDeleteBuilding` on `buildings.vue`, alongside
+  the dead bare `canDelete`), so the dead prop was never wired to anything on screen. Deleting
+  it changes no behaviour for any caller — it was already inert — and removes a prop whose
+  `default: true` looked like a live fail-open gate on a quick read.
+
+  This is unrelated to the `test/gate-defaults.test.mjs` contract (54 props / 22 components,
+  landed in #1277/#1278): none of these seven appear in that list, since that sweep only
+  covers props confirmed to be both bound by every caller AND actually read by the component.
+  `yarn test` still reports 279 passing, 0 failing.
+
+- e9931aa: Remove twelve inert `definePageMeta` calls from components
+
+  `definePageMeta` is a pages-only compiler macro. In a component it is a no-op,
+  so these twelve calls set neither `middleware` nor `memberOnly` — they only read
+  as though the component secured itself. `memberOnly` is what makes
+  `plugins/secure-member.client.ts` populate `userAppRole`, and without it every
+  `can*` gate in the package answers `false`; the flag has to be on the consuming
+  page. Deleting the calls changes no behaviour and stops them being mistaken for
+  protection that is already in place.
+
+- f2f594b: Resolve `userAppRole` once per signed-in session, on every authenticated route
+
+  The `secure-member` plugin is the only writer of `userAppRole` in the whole
+  system, and it returned early unless the route carried `memberOnly: true`. On
+  every other page the role stayed `null` for the life of the page, so permission
+  gates that default open granted controls to accounts that had no such
+  permission, and gates that fail closed denied them to real staff permanently.
+
+  Role resolution now runs for any authenticated route and is awaited before the
+  navigation completes, so no gate is evaluated against an unresolved role. A new
+  `userAppRoleStatus` (`"idle" | "loading" | "resolved"`) and `isAppRoleResolved`
+  on `useLocalSetup()` let an app tell "not loaded yet" apart from "loaded, and
+  this account genuinely holds no member document" — the second is the correct
+  final answer for Seven365 staff-console accounts and residents, and is no
+  longer a reason to redirect. A failed request stays unresolved and retries on
+  the next navigation instead of denying for the rest of the session.
+
+  The `memberOnly` redirects are unchanged, and no permission gate was touched.
+
+- eaa8500: Wire the three dead role permissions, and stop a refused roles list looking like an empty one
+
+  `RolePermissionMain` declared `canViewRole`, `canViewByRole` and `canUpdateRole`
+  and referenced none of them. Ten pages across the estate pass them in good faith,
+  so "See all roles", "See role details" and "Update role" were switches that did
+  nothing: the row click was ungated and `RolePermissionFormPreviewUpdate` had no
+  permission prop at all, showing Edit to everybody. `canViewRole` and
+  `canViewByRole` now default to `true`, which is exactly the behaviour the nine
+  pages that do not pass them have always had.
+
+  The roles table also rendered "No data available" for three different situations
+  -- you may not see roles, the request failed, and this organisation has none. It
+  now says which. And both role forms read `error.response._data.message`
+  unguarded, so a network or timeout failure threw inside its own catch and showed
+  the user nothing; the message the preview dialog does show was also duplicated in
+  the template and printed twice.
+
+- 159aa53: ServiceProviderMain now derives its add/invite/view gates from a real permission catalogue entry when the caller omits them
+
+  `canAddServiceProvider`, `canInviteServiceProvider` and `canViewServiceProviders` all
+  declared `default: true`, and no app bound any of the three -- there was no permission
+  catalogue key anywhere in the package for an app to bind them to, so every signed-in user
+  in every consumer could add, invite and view service providers regardless of role.
+
+  Added a `service-provider` family (`add-service-provider`, `invite-service-provider`,
+  `see-all-service-providers`) to `useCommonPermission`'s catalogue and a new
+  `useServiceProviderPermission` composable that reads it, the same shape as the existing
+  `useBulletinBoardPermission` / `useSettingsPermission` gates. `ServiceProviderMain` now
+  reads that composable as the fallback when a prop is unbound
+  (`props.canAddServiceProvider ?? derived.value`, etc.) -- an app that already passes a
+  prop explicitly still wins.
+
+  This closes the gap in-package. It does not add server-side enforcement:
+  `service-provider.route.ts` only requires an authenticated session today, the same as
+  `bulletin-board.route.ts` -- this catalogue key is the same frontend-only enforcement
+  layer the rest of this family already relies on, not a new pattern.
+
 ## 4.0.2
 
 ### Patch Changes
@@ -17,11 +280,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/useLocalSetup.ts

@@ -1,12 +1,38 @@
 export function useLocalSetup() {
   const userAppRole = useState<TRole | null>("userAppRole", () => null);
 
+  // Where the `userAppRole` lookup has got to. `userAppRole` on its own cannot
+  // say this, and conflating the two states below is what caused both halves of
+  // the permission bug:
+  //
+  //   "idle" | "loading" -- nobody has resolved a role yet, or one is in
+  //                         flight. NOT an answer. A gate read here must not
+  //                         grant, and an app that cares should render a
+  //                         loading state rather than guess.
+  //   "resolved"         -- the lookup finished. `userAppRole` is either the
+  //                         role, or `null` because this account genuinely
+  //                         holds no member document for this app. Seven365
+  //                         staff-console accounts and residents never hold
+  //                         one, and "no role" is the correct final answer for
+  //                         them -- not a failure, and not a reason to redirect.
+  //
+  // A failed request drops back to "idle", never to "resolved", so a transient
+  // blip retries on the next navigation instead of denying for the whole session.
+  const userAppRoleStatus = useState<"idle" | "loading" | "resolved">(
+    "userAppRoleStatus",
+    () => "idle"
+  );
+
+  const isAppRoleResolved = computed(() => userAppRoleStatus.value === "resolved");
+
   const id = useState<string | null>("memberShipOrgId", () => null);
 
   const orgNature = useState<string>("orgNature", () => "");
 
   return {
     userAppRole,
+    userAppRoleStatus,
+    isAppRoleResolved,
     id,
     orgNature,
   };

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.0.3-staging.235",
+  "version": "4.0.3",
   "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/plugins/secure-member.client.ts

@@ -4,20 +4,82 @@ const hexSchema = z
   .string()
   .regex(/^[0-9a-fA-F]{24}$/, "Invalid organization ID");
 
+function statusOf(error: any) {
+  return error?.statusCode ?? error?.status ?? error?.response?.status;
+}
+
 export default defineNuxtPlugin(() => {
   const router = useRouter();
   const { getByUserType } = useMember();
   const { getRoleById } = useRole();
   const { getById } = useOrg();
 
-  const { userAppRole, id, orgNature } = useLocalSetup();
+  const { userAppRole, userAppRoleStatus, id, orgNature } = useLocalSetup();
+
+  // Resolved once per signed-in session, not once per navigation. Keyed by the
+  // user cookie so signing in as somebody else re-resolves.
+  let resolvedFor: string | null = null;
+  let inFlight: Promise<void> | null = null;
+  let hasMemberDocument = false;
+
+  // Deliberately never redirects and never throws.
+  //
+  // `GET /api/members/user/:id/app/:type` returns 404 for any account holding no
+  // member document for this app -- the Seven365 staff console and residents
+  // both do -- and that is a real answer ("no organisation role"), not an error.
+  // Treating it as an error is what would bounce those accounts off their own
+  // pages; leaving it unanswered is what let gates fail open.
+  async function resolveAppRole(userId: string) {
+    if (resolvedFor === userId) return;
+    if (inFlight) return inFlight;
+
+    userAppRoleStatus.value = "loading";
+    inFlight = run(userId).finally(() => {
+      inFlight = null;
+    });
+    return inFlight;
+  }
+
+  async function run(userId: string) {
+    const APP = useRuntimeConfig().public.APP;
+
+    try {
+      // The org query is not sent: the endpoint keys on user + app type only, so
+      // the role does not depend on which organisation is in the current route.
+      const member = await getByUserType(userId, APP);
+      hasMemberDocument = true;
+      id.value = member.org ?? "";
+      userAppRole.value = member.role ? await getRoleById(member.role) : null;
+    } catch (error) {
+      userAppRole.value = null;
+      hasMemberDocument = false;
+      // Anything that is not a 404 is transient. Stay unresolved so the next
+      // navigation tries again rather than denying for the rest of the session.
+      if (statusOf(error) !== 404) {
+        userAppRoleStatus.value = "idle";
+        return;
+      }
+    }
+
+    resolvedFor = userId;
+    userAppRoleStatus.value = "resolved";
+  }
 
   router.beforeEach(async (to) => {
+    const userId = useCookie("user").value ?? "";
+
+    // Resolve for EVERY authenticated route, not only `memberOnly` ones. Gates
+    // are read on pages that carry no such flag -- the staff console cannot
+    // carry it at all, it has no organisation in the route -- and until this
+    // ran there the role stayed null for the life of the page: gates that
+    // default open granted everything, gates that fail closed denied everything.
+    // Awaited, so no gate is ever evaluated against an unresolved role.
+    if (userId) await resolveAppRole(userId);
+
     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) || "";
 
@@ -25,27 +87,19 @@ export default defineNuxtPlugin(() => {
       return { name: "require-organization-membership" };
     }
 
-    const userId = useCookie("user").value ?? "";
     if (!userId) return { name: "index" };
 
-    try {
-      const userMemberData = await getByUserType(userId, APP, org);
-      id.value = userMemberData.org ?? "";
-
-      const [orgResult, roleResult] = await Promise.allSettled([
-        getById(org),
-        userMemberData.role ? getRoleById(userMemberData.role) : null,
-      ]);
-
-      if (orgResult.status === "fulfilled" && orgResult.value) {
-        orgNature.value = orgResult.value.nature ?? "";
-      }
+    // Same bounce as before for an account with no member document. Gated on a
+    // finished lookup so a failed request no longer throws the user out.
+    if (userAppRoleStatus.value === "resolved" && !hasMemberDocument) {
+      return { name: "index" };
+    }
 
-      if (roleResult.status === "fulfilled" && roleResult.value) {
-        userAppRole.value = roleResult.value;
-      }
+    try {
+      const orgResult = await getById(org);
+      if (orgResult) orgNature.value = orgResult.nature ?? "";
     } catch (error) {
-      return { name: "index" };
+      // Cosmetic only, and it never blocked navigation before either.
     }
   });
 });