@7365admin1/core 3.53.6 → 3.53.8

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # @iservice365/core
 
+## 3.53.8
+
+### Patch Changes
+
+- c0298c6: Notification Settings: remove the two switches that governed nothing.
+
+  - Service Provider Invitations no longer offers a movable **Email** switch. No sender in the estate
+    ever calls the preference guard with `"email"`, so the switch a person could move did not suppress
+    the invitation email. The row is now dimmed with the reason, matching every other category.
+  - **Emergency Contacts** is no longer offered at all. Its sender exists here, but emergency contacts
+    are written in `iservice365-API-core` and the change that would have called it from there was
+    closed, not merged — so the switch governed a message that cannot arrive. It returns to the screen
+    the day a caller exists, with no schema change.
+
+  No delivery behaviour changes: nothing starts or stops being sent, and a person with no stored
+  preference behaves exactly as before.
+
+## 3.53.7
+
+### Patch Changes
+
+- 185f92a: Scope the invitation list and cancel: `GET /api/verifications` refuses an estate-wide read to anyone who is not Seven365 staff, and `PUT /api/verifications/:id/cancel` authorizes against the stored verification's organisation.
+
 ## 3.53.6
 
 ### Patch Changes

package/dist/index.d.ts

@@ -13511,13 +13511,16 @@ declare class NotificationService {
  * A switch that governs a notification nobody sends is a lie to the user, so a
  * category is only `rendered` once something in the estate actually sends it.
  *
- * The four `safety: true` entries below now send: `NotificationService` has an
- * incident, emergency-contact, patrol and camera-fault sender, and each resolves
- * its recipients from role permissions at the site the event happened on. Three
- * of the four are wired to a live trigger; the emergency-contact sender is
- * called from `iservice365-API-core`, where that module lives. Camera faults
- * still ALSO raise the live socket toast they always did — the stored
- * notification is added beside it, not instead of it.
+ * Three of the four `safety: true` entries below send: `NotificationService`
+ * has an incident, patrol and camera-fault sender wired to a live trigger, and
+ * each resolves its recipients from role permissions at the site the event
+ * happened on. Camera faults still ALSO raise the live socket toast they always
+ * did — the stored notification is added beside it, not instead of it.
+ *
+ * The fourth, `emergencyContact`, is `rendered: false`: its sender exists here
+ * but emergency contacts are written in `iservice365-API-core`, and the change
+ * that would have called it from there was closed rather than merged. It goes
+ * back on the screen the day a caller exists, with no schema change.
  *
  * The two marketplace order entries are the one place that rule is stretched:
  * they are `rendered` before their senders exist, because the senders live in
@@ -13534,10 +13537,13 @@ declare class NotificationService {
  * deliver, with the reason in `channelNote` — the house pattern is to show a
  * control and explain why it is unavailable, never to hide it.
  *
- * Email is `false` almost everywhere for a real reason: the module emails this
- * system sends are addressed to an email string stored on a record (a booking's
- * contact, a visitor, a site's configured alert list), not to a user account, so
- * there is no user whose preference could be consulted. Account and sign-in mail
+ * 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
+ * contact, a visitor, an invited company, a site's configured alert list), not
+ * to a user account, so there is no user whose preference could be consulted.
+ * No sender in the estate calls `filterRecipients` or `isChannelEnabled` with
+ * `"email"`, so an email switch that a person could move would govern nothing —
+ * the dimmed switch and its note are the honest control. Account and sign-in mail
  * — one-time codes, address verification, password resets — is deliberately
  * absent from this list entirely and can never be switched off by anything here.
  */

package/dist/index.js

@@ -14846,7 +14846,10 @@ var NOTIFICATION_CATEGORIES = [
     key: "serviceProviderInvite",
     label: "Service Provider Invitations",
     description: "When a property manager invites your company to provide services at a site.",
-    channels: { inApp: true, push: true, email: true },
+    channels: { inApp: true, push: true, email: false },
+    channelNote: {
+      email: "The invitation email is the invitation itself \u2014 for a company that has no account here yet it is the only copy, so it is always sent to the address the invitation was addressed to. The switches above control the copy that reaches you inside the app."
+    },
     permissionResources: ["service-provider-mgmt"],
     rendered: true
   },
@@ -14873,7 +14876,12 @@ var NOTIFICATION_CATEGORIES = [
     channelNote: { email: NO_EMAIL_RECIPIENT },
     permissionResources: ["emergency-contact"],
     safety: true,
-    rendered: true
+    // Nothing sends this. The sender below exists, but the only place emergency
+    // contacts are written is `iservice365-API-core`, and the change that would
+    // have called it from there (API-core #997) was closed, not merged. Until a
+    // caller exists this stays out of the screen rather than offering a switch
+    // over a message that never arrives.
+    rendered: false
   },
   {
     key: "virtualPatrol",
@@ -15682,6 +15690,19 @@ async function requireUserFieldWrite(req, userId, field, grant) {
     return await requirePlatformStaff(req, grant);
   return await requireSelfOrPlatformStaff(req, userId, grant);
 }
+async function requireVerificationListReach(req, orgId) {
+  if (orgId) {
+    await requireOrgReach(req, orgId);
+    return;
+  }
+  await requirePlatformStaff(req);
+}
+async function requireVerificationReach(req, verification) {
+  const org = verification?.metadata?.org?.toString?.() ?? "";
+  if (!org)
+    return;
+  await requireOrgReach(req, org);
+}
 
 // src/services/service-provider-invite.service.ts
 var INVITE_VALID_HOURS = 72;
@@ -27652,6 +27673,7 @@ function useVerificationController() {
       });
     }
     try {
+      await requireVerificationListReach(req, orgId);
       const data = await _getVerifications({
         search,
         page,
@@ -27739,6 +27761,7 @@ function useVerificationController() {
       return;
     }
     try {
+      await requireVerificationReach(req, await _getVerificationById(otpId));
       await _cancelUserInvitation(otpId);
       res.json({
         message: "User invite has been cancelled."
@@ -85028,7 +85051,7 @@ function useVerificationControllerV2() {
     cancelUserInvitation: _cancelUserInvitation,
     resendSignUpVerification: _resendSignUpVerification
   } = useVerificationServiceV2();
-  const { getVerifications: _getVerifications } = useVerificationRepoV2();
+  const { getVerifications: _getVerifications, getVerificationById: _getVerificationById } = useVerificationRepoV2();
   async function verify(req, res, next) {
     try {
       const schema2 = import_joi142.default.object({ verificationCode: import_joi142.default.string().required() });
@@ -85209,6 +85232,7 @@ function useVerificationControllerV2() {
     }
     const { search, page, status, app, email, type } = value;
     try {
+      await requireVerificationListReach(req, null);
       const data = await _getVerifications({
         search,
         page,
@@ -85235,6 +85259,7 @@ function useVerificationControllerV2() {
       return;
     }
     try {
+      await requireVerificationReach(req, await _getVerificationById(otpId));
       await _cancelUserInvitation(otpId);
       res.json({
         message: "User invite has been cancelled."