@7365admin1/core 3.47.1-staging.139 → 3.47.1-staging.141

package/.changeset/estate-structure-write-scope.md

@@ -0,0 +1,51 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the estate-structure writes to the site they act on.
+
+`POST/PATCH/PUT` on `/api/buildings`, `/api/building-levels` and
+`/api/building-units` all carried `requireAuth` and nothing more. The site came
+from the request body on the creates and the record id came from the URL on the
+edits and deletes, and neither was checked against the caller. So any signed-in
+account on the platform could add a block to another client's estate, rename its
+levels in bulk, or delete its units — the records residents, visitor passes,
+billing and access rights are all hung off.
+
+Ten routes now decide from the site:
+
+- `POST /api/buildings/`, `POST /api/building-levels/`,
+  `POST /api/building-units/` — from the site named in the body, which is where
+  the new record lands.
+- `PATCH /api/buildings/id/:id`, `PUT /api/buildings/:id`,
+  `PUT /api/building-levels/id/:id`, `PUT /api/building-levels/:id`,
+  `PATCH /api/building-units/id/:id`, `PUT /api/building-units/:id` — the stored
+  record is loaded first and its own site decides. The id in the URL selects the
+  record; it never authorises it.
+- `PATCH /api/building-levels/batch` — EVERY id in the batch is checked, not
+  just the first, and only the distinct sites are looked up so renaming twelve
+  levels of one block stays one check.
+
+The rule is `entitleSite`, the site-reach rule the camera, HID and people
+modules already use: a membership pinned to the site, an org-wide membership at
+the site's owning organisation, or an ACTIVE `customer.sites` engagement. The
+engagement branch is required, not incidental — the estate structure is
+maintained from the property-management and service-provider apps, whose users
+may hold no membership in the estate's own organisation.
+
+The shared four lines live in a new `src/utils/site-reach.util.ts` so the same
+check is not written out in three controllers. It introduces no second
+mechanism: it resolves the caller with `resolveInviteActor` and defers to
+`entitleSite`, exactly as `person.controller.ts` does.
+
+A site the caller cannot reach answers as a site that does not exist, so site
+ids cannot be enumerated by watching the difference. A record with no site at
+all is refused rather than waved through.
+
+The READS on these three routers are deliberately unchanged. Six of them share
+a controller function with a pre-login signup alias
+(`/buildings/list/site/resident/:siteId`, `/building-levels/list/site/resident/:siteId`,
+`/building-units/resident/site/:site/block/:block/level/:level` and the three
+`resident` variants), which the resident mobile app calls before an account
+exists. Guarding the handler would break registration on a shipped client, so
+those need the alias split first.

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

@@ -0,0 +1,44 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the organisation lookups so they stop mapping one client to another.
+
+Four reads on `/api/organizations` carried `requireAuth` and nothing more, and
+every one took its key straight from the URL:
+
+- `GET /api/organizations/user/:user` — which organisations ANY person belongs to
+- `GET /api/organizations/orgs/:email` — the same, keyed on ANY email address
+- `GET /api/organizations/name/:name` — any organisation, by name
+- `GET /api/organizations/email/:email` — any organisation, by email address
+
+Together those are a cross-client directory and an account-enumeration oracle: a
+resident of one estate could map which clients an address or a user id belongs
+to across the whole platform.
+
+Each is now decided from the session:
+
+- `user/:user` — the caller's own id, or Seven365 staff. Every live caller asks
+  about itself: the seven service-provider app layouts, the org app, and the
+  resident mobile app all pass the signed-in user's own id.
+- `orgs/:email` — the caller's own address, compared case-insensitively after
+  being resolved from the session, or Seven365 staff. All three live callers
+  pass the signed-in user's own address.
+- `name/:name` — Seven365 staff. Its only caller is the staff console's client
+  list.
+- `email/:email` — Seven365 staff. No caller exists in any repository in the
+  organisation.
+
+A key that does not exist is refused exactly as one that does, so the refusal
+itself is not an oracle.
+
+`GET /api/organizations/id/:id` is deliberately NOT guarded here: the same
+controller function is mounted a second time, unauthenticated, at
+`/api/organizations/org/id/:id`, which the sign-up-invite screens call before an
+account exists. Guarding the handler would guard both mounts and break
+registration. That one needs the alias split first.
+
+`GET /api/organizations/` (the full client list) is also unchanged and is
+recorded as a decision for the leads: it is reached from a live signup path that
+must move onto the organisation `POST /api/organizations/onboarding` already
+returns before the list can be staff-gated.