@7365admin1/core 3.64.5-staging.304 → 3.64.5-staging.305
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.changeset/module-gate-kill-switch-and-read.md +26 -0
- package/dist/index.js +4 -0
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +4 -0
- package/dist/index.mjs.map +1 -1
- package/package.json +1 -1
- package/test/module-access.test.mjs +27 -0
- package/test/module-gate-kill-switch.test.mjs +48 -0
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Module gate: the kill switch now stops the 409, and the check stops reading when there is nothing to decide
|
|
6
|
+
|
|
7
|
+
Two follow-ups from the module-gate server review, both behaviour-neutral for
|
|
8
|
+
anybody who is not using the kill switch.
|
|
9
|
+
|
|
10
|
+
**`MODULE_LIST_GATE=off` now means off.** Every other part of the gate checked the
|
|
11
|
+
master switch; `mustAcknowledge` did not. So with the gate switched off, a save that
|
|
12
|
+
narrowed a client's module list was still refused with a 409 "acknowledge the impact
|
|
13
|
+
first" — the one lever a lead would reach for in an emergency, not working for the
|
|
14
|
+
one path that blocks a save from going through. Both the organisation and the site
|
|
15
|
+
save paths go through that function, so both are fixed. With the switch at its
|
|
16
|
+
default the 409 behaves exactly as before, and that is asserted.
|
|
17
|
+
|
|
18
|
+
**`moduleDeniedForCaller` no longer reads memberships when no list is enforced.** It
|
|
19
|
+
runs on every governed request and read the caller's memberships before finding out
|
|
20
|
+
whether there was anything to decide — and `members.user` has no index to use. It now
|
|
21
|
+
returns early unless the site or its organisation has an enforced list, which is what
|
|
22
|
+
the notification filter already did. No verdict changes: a client that really has an
|
|
23
|
+
enforced list is still measured exactly as before, and that is asserted too.
|
|
24
|
+
|
|
25
|
+
Also corrects the 3.65.0 changelog, which claimed `MODULE_LIST_GATE` switched all of
|
|
26
|
+
the gate off at once. It did not, for the reason above.
|
package/dist/index.js
CHANGED
|
@@ -15855,6 +15855,8 @@ function deniedForMembership({
|
|
|
15855
15855
|
return { denied, since: [orgTier.since, siteTier.since].sort().pop() ?? "" };
|
|
15856
15856
|
}
|
|
15857
15857
|
function mustAcknowledge(preview, acknowledged) {
|
|
15858
|
+
if (!moduleListGateOn())
|
|
15859
|
+
return false;
|
|
15858
15860
|
if (acknowledged === true || !preview.newlyDenied.length)
|
|
15859
15861
|
return false;
|
|
15860
15862
|
return !preview.impact || preview.impact.memberCount > 0;
|
|
@@ -96883,6 +96885,8 @@ async function moduleDeniedForCaller({
|
|
|
96883
96885
|
if (!user || !siteId)
|
|
96884
96886
|
return ALLOW;
|
|
96885
96887
|
const siteDoc = typeof site === "string" ? await data.site(siteId).catch(() => null) : site ?? null;
|
|
96888
|
+
if (!await siteHasEnforcedList(siteDoc, data))
|
|
96889
|
+
return ALLOW;
|
|
96886
96890
|
const gate = await gateAtSite(await data.membershipsOf([user]), siteDoc, siteId, data);
|
|
96887
96891
|
if (gate.exempt)
|
|
96888
96892
|
return ALLOW;
|