@7365admin1/core 3.55.0 → 3.57.0
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/CHANGELOG.md +77 -0
- package/dist/index.js +4467 -4369
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +1783 -1685
- package/dist/index.mjs.map +1 -1
- package/package.json +2 -2
- package/test/e2e/harness.mjs +2 -0
- package/test/e2e/onboarding-org-save-diagnosis.e2e.test.mjs +76 -3
- package/test/e2e/org-default-roles.e2e.test.mjs +320 -0
- package/test/org-default-roles.test.mjs +218 -0
- package/test/role-scope-separation.test.mjs +195 -0
- package/test/role-scope.test.mjs +55 -3
- package/tools/role-scope-lockout-check/check.js +316 -0
- package/tools/role-scope-lockout-check/platform-only-permissions.json +21 -0
- package/tools/role-scope-lockout-check/srv.js +39 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,82 @@
|
|
|
1
1
|
# @iservice365/core
|
|
2
2
|
|
|
3
|
+
## 3.57.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 4b1f024: **A new client organisation is now created with its own owner roles.**
|
|
8
|
+
|
|
9
|
+
Measured on staging: of 195 live organisations, **74 hold not one role**, and not
|
|
10
|
+
one of those 74 has a subscription. The paid signup path
|
|
11
|
+
(`subscription.service.ts createOrgSubscription`) has always seeded two roles
|
|
12
|
+
named `owner` with `permissions: ["*"]`; the paths that actually create clients
|
|
13
|
+
today seeded nothing:
|
|
14
|
+
|
|
15
|
+
- `POST /organizations` — the Seven365 console creating a client
|
|
16
|
+
- `POST /organizations/onboarding` — step 1 of the client wizard
|
|
17
|
+
- `POST /customers` — `customer.service.ts createCustomer`
|
|
18
|
+
|
|
19
|
+
An organisation with no role of its own has nothing to invite anybody with,
|
|
20
|
+
which is why the console's invite picker offers the ORG-LESS templates instead:
|
|
21
|
+
the shared documents that one console save took every client's modules away with.
|
|
22
|
+
|
|
23
|
+
Those three paths now seed the same two roles the paid path already does, from a
|
|
24
|
+
single definition in `utils/org-default-roles.util.ts`. `subscription.service.ts`
|
|
25
|
+
is unchanged.
|
|
26
|
+
|
|
27
|
+
**NEW ORGANISATIONS ONLY.** Nothing is backfilled, migrated or rewritten. The
|
|
28
|
+
helper is only ever handed an id that was inserted a moment earlier, and it
|
|
29
|
+
returns no roles at all when it is handed no organisation — so it cannot produce
|
|
30
|
+
another org-less shared template. Existing organisations, roles, members and
|
|
31
|
+
users are untouched, asserted byte-for-byte in
|
|
32
|
+
`test/e2e/org-default-roles.e2e.test.mjs`.
|
|
33
|
+
|
|
34
|
+
`["*"]` is deliberate: it means everything, so a new client is never locked out
|
|
35
|
+
of anything, and no per-vertical permission catalogue is mirrored server-side to
|
|
36
|
+
drift out of date with the frontend's.
|
|
37
|
+
|
|
38
|
+
Seeding never fails the request that created the organisation. The two
|
|
39
|
+
controller paths do not run in a transaction, so a failed role insert is logged
|
|
40
|
+
and the organisation is returned exactly as those endpoints returned it before
|
|
41
|
+
this change.
|
|
42
|
+
|
|
43
|
+
## 3.56.0
|
|
44
|
+
|
|
45
|
+
### Minor Changes
|
|
46
|
+
|
|
47
|
+
- dc09517: Separate Seven365's roles from a client's, and enforce it on the server
|
|
48
|
+
|
|
49
|
+
`role.controller.ts requireRoleOrg` sends every role with no `org` to the staff
|
|
50
|
+
console gate, on the assumption that org-less means "a platform role". It does
|
|
51
|
+
not. A role with `type: "organization"` and no `org` is a TEMPLATE that clients
|
|
52
|
+
are invited with — "Org Owner" is one document behind 119 live members and 320
|
|
53
|
+
invitations on staging — and the console could rewrite it.
|
|
54
|
+
|
|
55
|
+
On 2026-09-07 it did. The console's role editor renders `useAdminPermission`,
|
|
56
|
+
the eleven PLATFORM resources, and the save wrote all 34 of those strings onto
|
|
57
|
+
that template. An empty permission list means "everything"
|
|
58
|
+
(`console-permission.util.ts consoleRoleAllowsAll`), so the role granted
|
|
59
|
+
everything right up to the moment it held a non-empty list — and the list it
|
|
60
|
+
then held contained no client module at all. Every holder, in every client, lost
|
|
61
|
+
every module at once.
|
|
62
|
+
|
|
63
|
+
`role-scope.util.ts` adds the missing distinction — platform (`type: "admin"`),
|
|
64
|
+
client template (no `org`), client (`org` set) — and two refusals built on it:
|
|
65
|
+
|
|
66
|
+
- the four role WRITES refuse a shared client template outright. Reads are
|
|
67
|
+
untouched: 119 members read that role on every session, and refusing them is
|
|
68
|
+
the same outage from the other direction.
|
|
69
|
+
- `createRole`, `updateRole` and `updatePermissionsById` refuse a console
|
|
70
|
+
permission string being ADDED to a role that is not a platform role. Strings
|
|
71
|
+
already stored pass through, so no save that works today begins to fail —
|
|
72
|
+
including the 114 org roles whose `subscriptions:*` grants are a
|
|
73
|
+
resource-NAME collision with the console's, not a platform grant.
|
|
74
|
+
|
|
75
|
+
No document is written, migrated or classified. `tools/role-scope-lockout-check`
|
|
76
|
+
measures the change from the account side, per account type, the way org-api
|
|
77
|
+
#470 does for site scoping: 400 staging accounts across 12 types, **zero
|
|
78
|
+
refusals in every type**, and zero roles that could no longer be re-saved.
|
|
79
|
+
|
|
3
80
|
## 3.55.0
|
|
4
81
|
|
|
5
82
|
### Minor Changes
|