@7365admin1/core 3.47.1-staging.127 → 3.47.1-staging.130
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/service-provider-org-filter.md +17 -0
- package/.changeset/users-list-staff-guard.md +17 -0
- package/.changeset/users-v2-list-staff-guard.md +13 -0
- package/dist/index.js +312 -310
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +38 -36
- package/dist/index.mjs.map +1 -1
- package/package.json +1 -1
- package/test/service-provider-query-keys.test.mjs +102 -0
- package/test/staff-console-authz.test.mjs +58 -2
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Fix the ignored serviceProviderOrgId filter on GET /api/service-providers
|
|
6
|
+
|
|
7
|
+
`service-provider.controller.ts` `getServiceProviders` validated
|
|
8
|
+
`serviceProviderOrgId` in its Joi schema but read
|
|
9
|
+
`req.query.serviceProviderId`. Joi rejects unknown keys, so no caller could
|
|
10
|
+
ever send the name that was read — the value was permanently `undefined` and
|
|
11
|
+
the documented filter was silently ignored, answering with every service
|
|
12
|
+
provider rather than the one organisation's.
|
|
13
|
+
|
|
14
|
+
The read now uses the key the schema declares. The repository already handled
|
|
15
|
+
`serviceProviderOrgId` correctly, so nothing below the controller changes.
|
|
16
|
+
|
|
17
|
+
Raised in web-app-org #142.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Require Seven365 staff to read the platform-wide user list
|
|
6
|
+
|
|
7
|
+
`GET /api/users` was `requireAuth` only. It is not filtered by organisation or
|
|
8
|
+
by site, so it returns every account on the platform — every client's residents,
|
|
9
|
+
guards and cleaners — and any signed-in account could page through the lot.
|
|
10
|
+
|
|
11
|
+
It now calls `requirePlatformStaff`, the same gate the rest of the staff console
|
|
12
|
+
uses. No second mechanism is introduced.
|
|
13
|
+
|
|
14
|
+
The per-user endpoints in the same controller (`getById`, `getByEmail`,
|
|
15
|
+
`getUsersByOrgId`, the profile and password writes) are deliberately unchanged —
|
|
16
|
+
they are a person's own account, not a cross-tenant read — and a test pins that
|
|
17
|
+
so a later sweep cannot close them by reflex.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Require Seven365 staff to read the platform-wide user list on /api/users/v2 too
|
|
6
|
+
|
|
7
|
+
`/api/users` and `/api/users/v2` are separate mounts onto separate controllers,
|
|
8
|
+
each with its own copy of the same unfiltered platform-wide list. Gating only
|
|
9
|
+
v1 left the gate bypassable by adding `/v2` to the URL.
|
|
10
|
+
|
|
11
|
+
`user-v2.controller.ts` `getUsers` now calls `requirePlatformStaff`, the same
|
|
12
|
+
gate. The v2 per-user endpoints are unchanged, and the test that pins the v1
|
|
13
|
+
profile endpoints as ungated now covers both controllers.
|