@7365admin1/core 3.64.5-staging.302 → 3.64.5-staging.303

package/.changeset/notify-access-filter-on.md

@@ -0,0 +1,24 @@
+---
+"@7365admin1/core": minor
+---
+
+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.

package/dist/index.d.ts

@@ -14397,13 +14397,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

@@ -16560,7 +16560,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);
 }