@7365admin1/core 3.47.1-staging.133 → 3.47.1-staging.135

package/.changeset/member-read-and-status-scope.md

@@ -0,0 +1,40 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the member list and the member suspend/reactivate write to their own organisation.
+
+`GET /api/members` took its `org` and `siteId` straight out of the query string,
+and `PUT /api/members/:id/:status` took the member id straight out of the URL.
+Both carried `requireAuth` and nothing more. So any signed-in account on the
+platform could list another client's staff, and suspend or reactivate any member
+of any client.
+
+`GET /api/members` also had a hole in its own scope requirement. Line 170 refused
+a query that named neither an organisation nor a user — **unless**
+`type === "admin"`, which then listed Seven365's own staff to anybody signed in.
+
+Both now decide from the session:
+
+- `type=admin` requires Seven365 staff. That query belongs to the staff console
+  (`web-app-org pages/super-admin`), so it is gated rather than removed.
+- a caller-supplied `org` is checked with `requireOrgAccess` before it is used —
+  Seven365 staff, or a live member of that organisation.
+- `user` on its own stays open for the caller's OWN id, because "which
+  organisations am I a member of" is every service app's landing page
+  (`web-app-security pages/index.vue:118` and its siblings). Asking it about
+  somebody else now requires staff.
+- `PUT /api/members/:id/:status` loads the stored membership and authorises on
+  the organisation recorded on it — never one from the request. A membership with
+  no organisation is a platform staff row, and only Seven365 staff may touch it;
+  a missing org is refused, not waved through.
+
+Service providers are not special-cased and do not need to be: a provider holds a
+membership in the organisation whose site it works on — that is how
+`GET /api/members/user/:id/app/:type?org=` finds its own row at sign-in — so the
+guard app's member list (`isecure365-mobile-app
+src/features/patrol/use-patrol.ts:180`, which sends `org: site.org` with a
+`siteId`) passes on the ordinary rule.
+
+Nothing changes for a permitted caller: same response shape, same fields, same
+status.

package/.changeset/people-read-scope.md

@@ -0,0 +1,40 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `GET /api/people` to a site the caller can actually reach.
+
+The endpoint returns resident and visitor records — name, NRIC, contact number,
+unit, plate numbers — and filters on NRIC, contact and plate number. It carried
+`requireAuth` and nothing more, and took its `org` and `site` from the query
+string (`person.controller.ts:79-80, 93`). So any signed-in account on the
+platform could page through another estate's residents, or look a person up by
+NRIC across every client at once.
+
+The caller is now resolved from the session and the scope decided before
+anything is read:
+
+- a named `site` is checked with `entitleSite` — the same site-reach rule the
+  camera and HID modules already use: a membership at the site, an org-wide
+  membership at the site's owning organisation, or an ACTIVE `customer.sites`
+  engagement. Reusing it matters rather than being tidy: an agency contracted to
+  an estate holds no membership in that estate's organisation, so an
+  org-membership check would have locked every guard out of the site they work
+  at. A site the caller cannot reach answers exactly as a site that does not
+  exist, so site ids cannot be enumerated.
+- a named `org` is checked against the caller's own memberships.
+- naming neither — the NRIC, contact and plate lookups — is narrowed to the
+  caller's own organisations instead of searching the whole platform.
+- Seven365 staff keep cross-tenant reach, unchanged.
+
+Every live caller passes a site: `layer-common` `VisitorForm.vue`,
+`MemberInformation.vue` and `VehicleForm.vue` all pass the site the screen is
+open on, and the People list passes org and site from its route. The two
+composable functions that pass neither — `usePeople().findPersonByContact` and
+`findUsersByPlateNumber` — have no caller in any repository.
+
+`person.repo.getAll` gains an optional `orgs` filter for the last case. It
+applies only when no explicit `org` was given, so it cannot fight one, and its
+absence means "no restriction", which is what staff get.
+
+No response shape, status code or field changed for a permitted caller.

package/dist/index.d.ts

@@ -4570,7 +4570,7 @@ declare function useGuestManagementController(): {
 declare const site_people_namespace_collection = "site.people";
 declare function usePersonRepo(): {
     add: (value: TPerson, session?: ClientSession) => Promise<ObjectId>;
-    getAll: ({ search, page, limit, sort, status, dateFrom, dateTo, org, site, type, nric, contact, plateNumber, }: {
+    getAll: ({ search, page, limit, sort, status, dateFrom, dateTo, org, orgs, site, type, nric, contact, plateNumber, }: {
         search?: string | undefined;
         page?: number | undefined;
         limit?: number | undefined;
@@ -4579,6 +4579,13 @@ declare function usePersonRepo(): {
         dateFrom?: string | undefined;
         dateTo?: string | undefined;
         org?: string | undefined;
+        /**
+         * The organisations the CALLER may see, when they have named neither an
+         * organisation nor a site. Resolved from the session by the controller,
+         * never from the request. Absent means "no restriction" — which is what
+         * Seven365 staff get.
+         */
+        orgs?: string[] | undefined;
         site?: string | undefined;
         type?: string | undefined;
         nric?: string | undefined;