@7365admin1/core 3.53.6 → 3.53.8

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@7365admin1/core",
   "license": "MIT",
-  "version": "3.53.6",
+  "version": "3.53.8",
   "author": "7365admin1",
   "main": "dist/index.js",
   "module": "dist/index.mjs",

package/test/notification-category.util.test.mjs

@@ -13,6 +13,7 @@ import {
   ORG_MARKETPLACE_VENDOR_FIELD,
   categoriesForPermissions,
   categorySupportsChannel,
+  notificationCategory,
   notificationCategoryLabel,
 } from "./.build/utils/notification-category.util.mjs";
 
@@ -42,7 +43,7 @@ describe("notification categories", () => {
     }
   });
 
-  it("the four safety categories now send, and are on by default and switchable", () => {
+  it("the four safety categories are on by default and switchable", () => {
     const safety = NOTIFICATION_CATEGORIES.filter((c) => c.safety);
 
     assert.deepEqual(keys(safety), [
@@ -56,7 +57,6 @@ describe("notification categories", () => {
       // nothing about them is special-cased: no "locked" flag, so they behave
       // like any other switch.
       assert.ok(!("locked" in category));
-      assert.equal(category.rendered, true, category.key);
 
       // a safety alert is permission-scoped, never a resident default — a
       // category with no resource would reach nobody.
@@ -71,7 +71,6 @@ describe("notification categories", () => {
   it("a role holding only the safety module is offered only that switch", () => {
     const cases = {
       "incident-reports:create": "incidentReport",
-      "emergency-contact:update": "emergencyContact",
       "virtual-patrol:see-all": "virtualPatrol",
       "site-settings:update": "cameraFault",
     };
@@ -143,7 +142,7 @@ describe("notification categories", () => {
       (c) => c.channels.email,
     ).map((c) => c.key);
 
-    assert.deepEqual(emailCapable, ["serviceProviderInvite"]);
+    assert.deepEqual(emailCapable, []);
   });
 
   it("every channel a category cannot use explains itself in plain words", () => {
@@ -174,10 +173,50 @@ describe("notification categories", () => {
   it("channel support is a fact about the category, not a preference", () => {
     assert.equal(categorySupportsChannel("workOrder", "push"), true);
     assert.equal(categorySupportsChannel("workOrder", "email"), false);
-    assert.equal(categorySupportsChannel("serviceProviderInvite", "email"), true);
+    assert.equal(categorySupportsChannel("serviceProviderInvite", "email"), false);
     assert.equal(categorySupportsChannel("not-a-module", "push"), false);
   });
 
+  // -------------------------------------------------------------------------
+  // What the September 2026 audit fixed. Both of these FAIL against the
+  // catalogue as it stood before it: `serviceProviderInvite` declared
+  // `email: true` and `emergencyContact` declared `rendered: true`.
+  // -------------------------------------------------------------------------
+
+  it("no category offers a switchable Email row, because no sender reads one", () => {
+    // `filterRecipients`/`isChannelEnabled` are never called with "email"
+    // anywhere in the estate, so a movable Email switch would govern nothing.
+    for (const category of NOTIFICATION_CATEGORIES) {
+      assert.equal(
+        category.channels.email,
+        false,
+        `${category.key} offers a live Email switch that no sender consults`,
+      );
+      assert.ok(
+        category.channelNote?.email,
+        `${category.key} dims Email without saying why`,
+      );
+    }
+  });
+
+  it("emergency contacts are not offered, because nothing calls their sender", () => {
+    // The sender exists in `notification.service.ts`, but emergency contacts
+    // are written in `iservice365-API-core` and the caller there was never
+    // merged. A switch over a message that cannot arrive is the defect this
+    // whole catalogue exists to prevent.
+    const category = notificationCategory("emergencyContact");
+    assert.equal(category.rendered, false);
+
+    for (const permissions of [["emergency-contact:update"], ["*"]]) {
+      assert.ok(
+        !keys(categoriesForPermissions({ permissions, isResident: true })).includes(
+          "emergencyContact",
+        ),
+        `offered to ${permissions.join()}`,
+      );
+    }
+  });
+
   it("category keys are unique", () => {
     const all = NOTIFICATION_CATEGORIES.map((c) => c.key);
     assert.equal(new Set(all).size, all.length);
@@ -332,7 +371,6 @@ const BEFORE = {
     "prelovedMarketplace",
     "serviceProviderInvite",
     "incidentReport",
-    "emergencyContact",
     "virtualPatrol",
     "cameraFault",
   ],
@@ -340,7 +378,7 @@ const BEFORE = {
     "bulletin-board": ["bulletinBoard"],
     "bulletin-board-mgmt": ["bulletinBoard"],
     "bulletin-videos-mgmt": ["bulletinBoard"],
-    "emergency-contact": ["emergencyContact"],
+    "emergency-contact": [],
     "event-mgmt": ["event"],
     "facility-booking-mgmt": ["facilityBooking"],
     "facility-mgmt": ["facilityBooking"],
@@ -413,11 +451,7 @@ describe("existing categories are untouched by the marketplace addition", () =>
     for (const category of NOTIFICATION_CATEGORIES) {
       if (NEW_KEYS.includes(category.key)) continue;
 
-      assert.equal(
-        category.channels.email,
-        category.key === "serviceProviderInvite",
-        category.key,
-      );
+      assert.equal(category.channels.email, false, category.key);
       assert.equal(category.channels.inApp, true, category.key);
       assert.equal(category.channels.push, true, category.key);
     }

package/test/verification-scope.test.mjs

@@ -0,0 +1,96 @@
+/**
+ * Listing and cancelling invitations both ask who is calling.
+ *
+ * `GET /api/verifications` took `orgId` as an OPTIONAL query filter with
+ * `requireAuth` in front and nothing else, so omitting it read every client's
+ * pending invitations. `PUT /api/verifications/:id/cancel` took the id off the
+ * URL with no authorization identifier in the handler at all, so any signed-in
+ * account could cancel any other client's invitations.
+ *
+ * What is pinned here is the wiring — the part that silently rots when somebody
+ * adds a filter, or copies one of these handlers to make a v3 — plus the two
+ * rules inside the gates themselves, because the rules are what make the fix
+ * lockout-free rather than merely closed.
+ *
+ * Nothing here opens a socket or a database. Every assertion reads a file.
+ */
+import test from "node:test";
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+
+const read = (rel) =>
+  readFileSync(fileURLToPath(new URL(`../src/${rel}`, import.meta.url)), "utf8");
+
+const v1 = read("controllers/verification.controller.ts");
+const v2 = read("controllers/verification-v2.controller.ts");
+const consoleAuthz = read("utils/console-authz.util.ts");
+
+/** One `async function name(...)` body out of a source file. */
+function fn(text, name) {
+  const start = text.indexOf(`async function ${name}(`);
+  assert.notEqual(start, -1, `${name} is no longer defined`);
+  const rest = text.slice(start);
+  const next = rest.slice(1).search(/\n *async function [a-zA-Z0-9_]+ ?\(/);
+  return next === -1 ? rest : rest.slice(0, next + 1);
+}
+
+/** [source, label, handler, the gate it must call, the call it guards] */
+const GUARDED = [
+  [v1, "v1", "getVerifications", "requireVerificationListReach(", "_getVerifications("],
+  [v2, "v2", "getVerifications", "requireVerificationListReach(", "_getVerifications("],
+  [v1, "v1", "cancelUserInvitation", "requireVerificationReach(", "_cancelUserInvitation("],
+  [v2, "v2", "cancelUserInvitation", "requireVerificationReach(", "_cancelUserInvitation("],
+];
+
+test("both list and both cancel handlers ask, and ask BEFORE the read or write", () => {
+  for (const [source, label, handler, gate, guarded] of GUARDED) {
+    const body = fn(source, handler);
+
+    assert.ok(
+      body.includes(gate),
+      `${label} ${handler} no longer calls ${gate}`
+    );
+    assert.ok(
+      body.indexOf(gate) < body.indexOf(guarded),
+      `${label} ${handler} calls ${guarded} before it is authorized`
+    );
+  }
+});
+
+test("the cancel gate reads the STORED verification, never the request", () => {
+  for (const [source, label] of [[v1, "v1"], [v2, "v2"]]) {
+    const body = fn(source, "cancelUserInvitation");
+    assert.match(
+      body,
+      /requireVerificationReach\(\s*req,\s*await _getVerificationById\(otpId\)/,
+      `${label} cancel must authorize against the stored record`
+    );
+  }
+});
+
+test("the v1 list gate is handed the caller's own orgId, not a literal", () => {
+  const body = fn(v1, "getVerifications");
+  assert.match(body, /requireVerificationListReach\(req, orgId\)/);
+});
+
+test("an omitted organisation costs Seven365 staff identity", () => {
+  const gate = fn(consoleAuthz, "requireVerificationListReach");
+  assert.ok(gate.includes("requireOrgReach(req, orgId)"), "the org branch is gone");
+  assert.ok(gate.includes("requirePlatformStaff(req)"), "the estate-wide branch is gone");
+  // The org branch must return, or a reaching member would then be asked for
+  // staff identity as well and every web app's invitations screen would 401.
+  assert.match(gate, /requireOrgReach\(req, orgId\);\s*\n\s*return;/);
+});
+
+test("a verification that names no organisation behaves exactly as before", () => {
+  const gate = fn(consoleAuthz, "requireVerificationReach");
+  // `createUserInvite` writes rows with an empty organisation and they are
+  // cancelled from the staff console. Refusing them would break a working
+  // screen; this early return is the zero-lockout half of the fix.
+  assert.match(gate, /if \(!org\) return;/);
+  assert.ok(
+    gate.indexOf("if (!org) return;") < gate.indexOf("requireOrgReach"),
+    "the org-less carve-out must come before the refusal"
+  );
+});