@7365admin1/core 3.54.0 → 3.56.0

package/CHANGELOG.md

@@ -1,5 +1,54 @@
 # @iservice365/core
 
+## 3.56.0
+
+### Minor Changes
+
+- dc09517: Separate Seven365's roles from a client's, and enforce it on the server
+
+  `role.controller.ts requireRoleOrg` sends every role with no `org` to the staff
+  console gate, on the assumption that org-less means "a platform role". It does
+  not. A role with `type: "organization"` and no `org` is a TEMPLATE that clients
+  are invited with — "Org Owner" is one document behind 119 live members and 320
+  invitations on staging — and the console could rewrite it.
+
+  On 2026-09-07 it did. The console's role editor renders `useAdminPermission`,
+  the eleven PLATFORM resources, and the save wrote all 34 of those strings onto
+  that template. An empty permission list means "everything"
+  (`console-permission.util.ts consoleRoleAllowsAll`), so the role granted
+  everything right up to the moment it held a non-empty list — and the list it
+  then held contained no client module at all. Every holder, in every client, lost
+  every module at once.
+
+  `role-scope.util.ts` adds the missing distinction — platform (`type: "admin"`),
+  client template (no `org`), client (`org` set) — and two refusals built on it:
+
+  - the four role WRITES refuse a shared client template outright. Reads are
+    untouched: 119 members read that role on every session, and refusing them is
+    the same outage from the other direction.
+  - `createRole`, `updateRole` and `updatePermissionsById` refuse a console
+    permission string being ADDED to a role that is not a platform role. Strings
+    already stored pass through, so no save that works today begins to fail —
+    including the 114 org roles whose `subscriptions:*` grants are a
+    resource-NAME collision with the console's, not a platform grant.
+
+  No document is written, migrated or classified. `tools/role-scope-lockout-check`
+  measures the change from the account side, per account type, the way org-api
+  #470 does for site scoping: 400 staging accounts across 12 types, **zero
+  refusals in every type**, and zero roles that could no longer be re-saved.
+
+## 3.55.0
+
+### Minor Changes
+
+- 8cbae97: Notification settings: deliver the marketplace in-app messages, and stop offering a channel that cannot deliver.
+
+  `NotificationModule` was missing the two tags `iservice365-API-core` sends for marketplace orders, so every in-app marketplace notification failed validation and was dropped inside the `catch` around the persist — the push arrived, the message never reached the app, and the "In the app" switch governed something that never happened. Both tags are now accepted; no other tag changed.
+
+  `GET /notification-preferences` now sends only the channels a category can actually deliver on. Email has no sender anywhere in the estate, so the screen was drawing a switch that could not move beside a sentence apologising for it, and then counting the two that could as "on everywhere". Every client renders what the server sends, so the dead row disappears from the web screen and both mobile screens at once. Where the reason was something a person actually needs — a booking confirmation goes to the address on the form — it is now said in the category's own description.
+
+  No stored preference changes, and no notification that was being delivered stops.
+
 ## 3.54.0
 
 ### Minor Changes

package/dist/index.d.ts

@@ -12911,6 +12911,8 @@ declare enum NotificationModule {
     FACILITY_BOOKING = "facilityBooking",
     ONLINE_FORM = "onlineForm",
     PRELOVED_MARKETPLACE = "prelovedMarketplace",
+    MARKETPLACE_ORDER = "marketplace-order",
+    MARKETPLACE_VENDOR_ORDER = "marketplace-vendor-order",
     INCIDENT_REPORT = "incidentReport",
     EMERGENCY_CONTACT = "emergencyContact",
     VIRTUAL_PATROL = "virtualPatrol",
@@ -13477,10 +13479,16 @@ declare class NotificationService {
  *
  * ## Channels are declared per category, not assumed
  *
- * `channels` says what this category can *physically* deliver on today. The
- * screen draws every channel for every category and dims the ones that cannot
- * deliver, with the reason in `channelNote` — the house pattern is to show a
- * control and explain why it is unavailable, never to hide it.
+ * `channels` says what this category can *physically* deliver on today, and it
+ * is what the settings screen is built from: `getForUser` sends only the
+ * channels a category can actually use, so a person is never shown a switch
+ * that will not move. `channelNote` is the reason a channel is off, kept here
+ * for whoever reads this file and pinned by a test — it is not sent to a
+ * client, because an apology beside a dead control is not a setting.
+ *
+ * Where the reason is something a person actually needs (a booking
+ * confirmation goes to the address on the form), it is said in the category's
+ * own `description`, which the screen does show.
  *
  * Email is `false` everywhere for a real reason: the module emails this system
  * sends are addressed to an email string stored on a record (a booking's
@@ -13671,10 +13679,12 @@ type NotificationPreferenceView = {
         channels: Array<{
             key: string;
             label: string;
-            /** false = drawn, dimmed, and not switchable */
+            /**
+             * Always true. Only channels this category can really deliver on are
+             * sent at all; the field stays so a client written against the older
+             * shape, which filtered on it, keeps working unchanged.
+             */
             supported: boolean;
-            /** plain-English reason, present only when unsupported */
-            note?: string;
             enabled: boolean;
         }>;
     }>;