@7365admin1/core 3.66.0 → 3.67.0

package/CHANGELOG.md

@@ -1,5 +1,30 @@
 # @iservice365/core
 
+## 3.67.0
+
+### Minor Changes
+
+- 7b9ea2f: Notifications: stop sending alerts for modules a client was never given
+
+  `NOTIFY_ACCESS_FILTER` now defaults to `on` instead of `log`, so the module-based
+  drop is real: a recipient no longer gets a notification when every membership they
+  hold at the site denies every module the notification's category is about.
+
+  Only the module drop acts. The role-based check is still computed and logged and
+  never drops anybody, because most apps do not enforce their role gates yet and a
+  role-based drop would hide alerts for screens people can still open.
+
+  Unchanged: residents, anyone with no membership at the site, Seven365 staff, sends
+  with no site, and categories the catalogue does not govern are all exempt; any
+  error sends to everyone; and `MODULE_LIST_GATE=off` still disables it entirely.
+  `NOTIFY_ACCESS_FILTER=log` or `off` overrides this default with no deploy.
+
+  This is inert until a client's module list is enforced — measured read-only on
+  staging at the time of the flip, no organisation (0 of 199) and no site (0 of 256)
+  had a stored list and there were no acknowledged-save markers, so nothing is
+  dropped for anybody until a Super Admin saves a module list with the acknowledged
+  preview.
+
 ## 3.66.0
 
 ### Minor Changes

package/dist/index.d.ts

@@ -14185,13 +14185,29 @@ declare function isPlatformOwner(userId?: string | ObjectId | null): Promise<boo
  * with no site (marketplace, broadcasts); a category not in the catalogue or
  * with no permission resources (resident-only and marketplace ones).
  *
- * `NOTIFY_ACCESS_FILTER`: `log` (code default) counts, logs and SENDS TO
- * EVERYONE; `on` drops; `off` reads nothing. `MODULE_LIST_GATE=off` is the
- * same as `off`. Any error sends to everyone.
+ * `NOTIFY_ACCESS_FILTER`: `on` (code default) DROPS; `log` counts, logs and
+ * sends to everyone; `off` reads nothing. `MODULE_LIST_GATE=off` is the same as
+ * `off`. Any error sends to everyone.
+ *
+ * The default was `log` from the day this shipped until the owner turned it on
+ * (2026-09-13), having accepted that some staff will notice alerts they used to
+ * get stopping. Only the MODULE drop became real; the role check above stays
+ * logged only, because most apps still do not enforce their role gates.
+ *
+ * Turning it on changed nothing on its own: the filter returns early unless the
+ * site or its organisation has an ENFORCED module list, and on the day of the
+ * flip no organisation and no site had one (measured read-only on staging: 0 of
+ * 199 organisations, 0 of 256 sites, 0 acknowledged-save markers). It takes
+ * effect for a client the first time a Super Admin saves that client's module
+ * list with the acknowledged preview.
+ *
+ * The env var still wins over this default, so a lead can put it back to `log`
+ * or `off` without waiting for a deploy.
  *
  * Both senders call this: core's `notification.service.ts send()` here, and
  * API-core's own `send()` (a separate class; memory
- * `two-notification-senders-not-one`), which must call it the same way.
+ * `two-notification-senders-not-one`), which imports this very function — so
+ * this default governs both, and neither can drift from the other.
  */
 type TNotifyAccessMode = "log" | "on" | "off";
 declare const NOTIFY_ACCESS_FILTER_DEFAULT: TNotifyAccessMode;

package/dist/index.js

@@ -16549,7 +16549,7 @@ async function siteModulePreview(site, org, proposed, data = moduleGateData()) {
 }
 
 // src/utils/notification-access.util.ts
-var NOTIFY_ACCESS_FILTER_DEFAULT = "log";
+var NOTIFY_ACCESS_FILTER_DEFAULT = "on";
 function notifyAccessMode(env2 = process.env) {
   return gateMode(env2.NOTIFY_ACCESS_FILTER, ["log", "on", "off"], NOTIFY_ACCESS_FILTER_DEFAULT);
 }