@7365admin1/layer-common 4.0.3-staging.221 → 4.0.3-staging.223

package/components/AccessCardPreviewDialog.vue

@@ -366,9 +366,11 @@ const props = defineProps({
     type: Boolean,
     default: true,
   },
+  // Fail closed. `AccessManagement` did not forward this, so the dialog's
+  // Assign control defaulted to open for every role.
   canAssignToPerson: {
     type: Boolean,
-    default: true,
+    default: false,
   },
   isSelectedCardAssignedPhysical: {
     type: Boolean,

package/components/AccessManagement.vue

@@ -93,6 +93,10 @@
     </v-dialog>
 
     <!-- Preview Dialog -->
+    <!-- `can-assign-to-person` uses the same rule the list view applies to its
+         own Assign control (line 15). It was not forwarded at all, so the
+         dialog fell back to its default and offered Assign to a role the list
+         view denies it to. -->
     <AccessCardPreviewDialog
       v-model="previewDialog"
       :unit="selectedCard"
@@ -100,6 +104,7 @@
       :can-update="canUpdateAccessCard"
       :can-replace-access-card="canReplaceAccessCard"
       :can-delete-access-card="canDeleteAccessCard"
+      :can-assign-to-person="canUpdateAccessCard && canAssignAccessCard"
       :is-selected-card-assigned-physical="isSelectedCardAssignedPhysical"
       :is-selected-card-physical="isSelectedCardPhysical"
       :site-id="siteId"

package/components/BuildingManagement/units.vue

@@ -36,8 +36,12 @@
     </v-dialog>
 
     <v-dialog v-if="canViewUnitDetails" v-model="dialogPreview" :width="smAndUp ? '70svw' : '100%'" persistent>
+      <!-- The host app passes `canUpdateUnit` / `canDeleteUnit` and they were
+           never forwarded, so `BuildingUnitFormEdit` fell back to its own
+           defaults and drew Update and Delete for a role that holds neither. -->
       <BuildingUnitFormEdit v-if="selectedBuildingUnit" @cancel="dialogPreview = false" @success="successUpdate()"
-        @delete-unit="openDeleteDialog()" :roomFacility="selectedBuildingUnit" />
+        @delete-unit="openDeleteDialog()" :roomFacility="selectedBuildingUnit" :canUpdateUnit="canUpdateUnit"
+        :canDeleteUnit="canDeleteUnit" />
     </v-dialog>
 
     <v-dialog v-model="dialogDelete" :loading="deleteLoading" width="450" persistent>

package/components/BuildingUnitFormEdit.vue

@@ -304,13 +304,16 @@ const prop = defineProps({
     type: Object as PropType<TBuildingUnit>,
     required: true,
   },
+  // Fail closed. A caller that forgets these must not be handed Update and
+  // Delete by default -- that is what happened when `BuildingManagement/units`
+  // did not forward them.
   canUpdateUnit: {
     type: Boolean,
-    default: true,
+    default: false,
   },
   canDeleteUnit: {
     type: Boolean,
-    default: true,
+    default: false,
   }
 });
 

package/composables/useCleaningPermission.ts

@@ -15,7 +15,33 @@ export default function useCleaningPermission() {
     roles: rolePermissions,
     invitations: invitationPermissions,
     "bulletin-board": bulletinBoardPermissions,
- 
+
+    // `hasPermission` looks an action up as `catalogue[resource][action]`, so a
+    // resource with no key here can never answer anything but `false` -- the
+    // gate is then reachable only through the `"*"` short-circuit. These two
+    // were checked by `-hygiene` (`site-settings:can-view-site-settings`,
+    // `:can-manage-site-settings`, `toilet_locations:create-toilet-location`)
+    // and were missing from this catalogue entirely, so every non-wildcard role
+    // was refused. Action names and shape copied from the sibling module
+    // catalogues that already work -- `usePoolMaintenancePermission` and
+    // `useLandscapingPermission` both spell it exactly this way.
+    "site-settings": {
+      "can-view-site-settings": {
+        check: true,
+        description: "Allows the user to view site settings.",
+      },
+      "can-manage-site-settings": {
+        check: true,
+        description: "Allows the user to manage and update site settings.",
+      },
+    },
+    toilet_locations: {
+      "create-toilet-location": {
+        check: true,
+        description: "Allows the user to create/add a toilet location.",
+      },
+    },
+
     inventory: {
       "view-inventory": {
         check: true,

package/package.json

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