@7365admin1/core 3.48.0 → 3.48.1-staging.149

package/.changeset/access-management-site-scope.md

@@ -0,0 +1,59 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the access-management routes to a site the caller can reach.
+
+Every route on `/api/access-management` carried `requireAuth` and nothing more.
+`requireAuth` proves a session exists; it makes no organisation or site
+decision. So any signed-in account on the platform — a resident of a different
+estate, a cleaner, anybody with a login — could read another client's
+access-card inventory, its card holders, the residents behind a unit and the
+block/level/unit structure, and could ISSUE a physical NFC card into that
+estate, generate visitor QR passes for it and stamp QR tags onto its cards.
+These are the credentials that open that estate's doors and lifts.
+
+Twenty-eight handlers now decide from the site the request already names,
+before any work is done:
+
+- from the body — `addPhysicalCard`, `addNonPhysicalCard`, `acknowlegdeCard`,
+  `replaceCard`, `assignAccessCardToUnit`, `vmsgenerateQrCodes`,
+  `addVisitorAccessCard`;
+- from the query — `allAccessCardsCounts`, `availableAccessCards`,
+  `userTypeAccessCards`, `assignedAccessCards`, `assignedAccessCardsByUnit`,
+  `accessandLiftCards`, `doorAndLiftDropdown`, `visitorAccessCards`,
+  `bulkPhysicalAccessCard`, `getCardDetails`, `allQrTag`,
+  `availableCardContractors`, `getBlockLevelAndUnitList`, `getResidents`,
+  `userAccessCards`, `uploadTemplate`, `removeTemplate`, `qrCodeList`;
+- from the URL — `getCardReplacement`, `getAccessManagementSettings`, `addQrTag`.
+
+The rule is the existing one, `requireSiteReach` -> `entitleSite`: 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 — access cards are administered from the security and
+property-management apps, whose users hold no membership in the estate's own
+organisation.
+
+The guard writes its own response instead of throwing. Every handler in this
+controller wraps its body in `try { ... } catch { res.status(400|500) }` rather
+than calling `next(error)`, so a thrown `UnauthorizedError`/`NotFoundError`
+would never reach the error handler and would have surfaced as a 400 with the
+guard's message inside it. It is placed AFTER each handler's Joi validation, so
+a malformed or missing site still answers 400 exactly as before, and only a
+well-formed site the caller cannot reach is refused. That refusal is 404 — what
+a site that does not exist already answers — so site ids cannot be enumerated by
+watching the difference.
+
+Six routes on the mount are deliberately NOT changed, because they carry no
+site at all and need per-record resolution:
+
+- `POST /sign-qr` and `PATCH /visitor-checkout` — both are called by shipped
+  mobile clients that cannot update in lockstep
+  (`resident-mobile-app src/actions/entrypass.ts:66`, `isecure365-mobile-app
+  src/features/visitors/entry-pass.service.ts:175` and `visitor.service.ts:194`).
+- `PATCH /nfc-status`, `PATCH /delete-card`, `POST /card-replacement`,
+  `POST /assign-user` — each identifies a card by id and would need the card's
+  own site loaded first.
+- `GET /door-access-levels`, `GET /lift-access-levels`, `GET /access-groups` and
+  `POST /settings` take an `acm_url` — an access-control device URL — so they
+  are a separate question from site reach and were not touched here.

package/.changeset/customer-site-org-scope.md

@@ -0,0 +1,48 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `/api/customer-sites` to the organisations on the record.
+
+Every route on this module except the pre-login invite acceptance carried
+`requireAuth` and nothing more, and took the organisation straight out of the
+query string or the body (`customer-site.controller.ts`). Two things followed
+from that, and both are closed here.
+
+`POST /api/customer-sites` is not merely an engagement record: it CREATES A SITE
+inside whatever `siteOrg` the body names, and writes that site onto the
+organisation as its default when it has none
+(`customer-site.service.ts:77-111`). Any signed-in account on the platform — a
+resident, a cleaner, a guard — could therefore plant a site inside any client.
+
+A `customer.sites` row is also the cross-organisation access grant itself: the
+"engaged agency" branch of `resolveSiteAccess` reads it to decide who may reach
+a site's cameras, HID readers and residents
+(`camera-view.service.ts:325-341`). Being able to write, edit or delete those
+rows by id was being able to grant yourself reach into another client's estate,
+or revoke a contractor's.
+
+The caller is now resolved from the session and the decision made before
+anything is read or written:
+
+- `POST /` requires `requireOrgAccess` on the body's `org`, and on `siteOrg`
+  too when it names a different organisation — because that is where the new
+  site lands. The Add / Edit Site form sends the same id for both
+  (`web-app-org components/SiteForm.vue:397-402`).
+- `GET /` requires `requireOrgAccess` on the `org` filter the caller sends.
+- `GET /:id`, `PUT /:id` and `DELETE /:id` load the row first and decide from
+  the row's own `org` and `siteOrg` — Seven365 staff, or a live member of
+  EITHER side of the engagement. Either, not one: the estate's manager reaches
+  the row through `siteOrg` and the contracted agency reaches the same row
+  through `org`, so scoping to one side would break the other's screen.
+- `GET /service-provider/:id` takes a SITE id, and uses `entitleSite` — the
+  same site-reach rule the camera, HID and people modules already use, so an
+  agency contracted to a site still lists who else works there.
+
+`POST /invite/:id` is unchanged and still reachable with no session: an invited
+organisation accepts before it has an account (`web-app-main pages/sign-in.vue:182`).
+
+No new authorization mechanism is introduced. `requireOrgAccess` and
+`entitleSite` are the helpers the member, role, people, camera and HID paths
+already use, and the "either side" test is `resolveInviteActor` asked about two
+organisations in one round trip rather than two.

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/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/member-type-platform-staff-gate.md

@@ -0,0 +1,71 @@
+---
+"@7365admin1/core": minor
+---
+
+Only Seven365 staff can create a Seven365 staff membership.
+
+`members.type` decides who is platform staff. `isSuperAdmin` answers true for a
+live `members` row of type `"admin"` whose role is also of type `"admin"`, and
+that field was validated as `Joi.string().required()` — a free-form string with
+no allow-list. Every request path that writes a membership takes the value
+straight from the caller:
+
+- `POST /api/members/direct` writes the body's `app` verbatim as `type`
+  (`member.service.ts:137`);
+- `POST /api/auth/invite` stores the body's `app` on the invitation, and
+  accepting it writes that value as `type` (`member.service.ts:73`);
+- `PUT /api/members/id/:id/role/:role/type/:type/org/:org` re-pointed a
+  membership at any role, including the seeded platform one, checking only that
+  an owner role existed and that the target was not the last owner — never who
+  was asking.
+
+All three are `requireAuth`-only. So any signed-in account — a resident, a
+cleaner, a guard — could post `{ app: "admin" }`, or invite itself as `admin`
+and accept its own invitation, and be Seven365 platform staff on the next
+request. That defeats every gate built on `isSuperAdmin`: the staff console,
+service-provider approvals, the notification broadcast and client suspension.
+Executed end to end against a throwaway in-memory database, the chain succeeded
+at every step.
+
+Three changes, all fail-closed:
+
+- `members.type` now validates against `MEMBER_TYPES`, enumerated from the
+  values this package actually writes — `admin` (`user.service.ts`
+  `createDefaultUser` and the console's own invitations), `organization` (the
+  default in `member.service.ts`, `user.service.ts`, `user-v2.service.ts` and
+  `subscription.service.ts`), `resident` (`person.service.ts`), and the eight
+  `AppServiceType` service memberships, the same list `organization.model.ts`
+  already accepts as an organisation's `nature`.
+- `createMemberDirect` refuses `app: "admin"`, and refuses a role of type
+  `"admin"`, unless the caller is already platform staff. The caller is resolved
+  from the session by the controller and passed in; it is never read from a body
+  or a URL.
+- `createUserInvite` refuses `app: "admin"` unless the caller is already
+  platform staff, so the invitation road to the same place is shut too.
+
+`updateRoleById` refuses to move a membership onto a role of type `"admin"` for
+the same reason — that was step 6 of the chain, the one that turned
+`isPlatformOwner` true by pointing a membership at the seeded owner role.
+
+The seeded role marker `default: true` was re-checked rather than assumed and is
+still not forgeable: Joi rejects unknown keys on all three role schemas.
+
+Every legitimate caller across the sibling repos was checked and still works.
+`web-app-main pages/sign-in.vue` and `pages/verify/email/index.vue`, and
+`web-app-org pages/onboarding/getting-started/index.vue`, all pass
+`app: "organization"` or a service type — none reaches a gate. The one caller
+that does send `"admin"` is the staff console itself
+(`web-app-org pages/super-admin/invitations/index.vue:403`), operated by an
+account that already is staff.
+
+One transitional case is kept deliberately. `web-app-org
+pages/org/[organization]/invitations/invite.vue:122` and `web-app-hygiene
+pages/[org]/[site]/invitations/invite.vue:135` send the ORGANISATION ID as the
+invitation's `app`, so accepting one of those invitations writes an org id into
+`members.type`. That is a defect in those two screens, but it is live: the
+validator therefore also accepts a 24-character hex string, with the two file
+references named at the line, to be removed once both screens send a real
+membership type. It cannot be used to escalate — `"admin"` is not 24 hex
+characters, so the allow-list still decides that.
+
+No response shape, status code or field changed for a permitted caller.

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.

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/.changeset/person-lookup-scope.md

@@ -0,0 +1,44 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the single-value people lookups to a site the caller can reach.
+
+Seven endpoints on `/api/people` carried `requireAuth` and nothing else and were
+not scoped at all:
+
+| Route | What it answered |
+|---|---|
+| `GET /nric/:nric` | a `findOne` on NRIC across the **whole platform** |
+| `GET /contact/:contact` | the same, on contact number |
+| `GET /plateNumber/:plateNumber` | every person with that plate, anywhere |
+| `GET /unit/:unit` | every person at that unit id |
+| `GET /user/:userId` | the person record behind any user id |
+| `GET /company` | company names aggregated across every client |
+| `GET /all-nric` | a paged NRIC list at a caller-named site |
+
+So any signed-in account could type an NRIC or a car plate and read the matching
+resident of any estate — name, unit, contact number, plates. #1907 scoped the
+paged list (`GET /api/people`); these are the lookups beside it.
+
+None of them takes a site — `layer-common usePeople.findPersonByNRIC`,
+`searchCompanyList` and `getPeopleByUnit` pass only the value being looked up —
+so the scope is decided **after** the read, on the record, with the same
+site-reach rule the camera, HID and people-list already use. A record the caller
+cannot reach is left out, which for these endpoints is exactly what "no such
+person" already looked like: `null`, or an empty list. **No client sees a new
+response shape or a new status code.** `entitleSite` is asked once per distinct
+site, not once per record.
+
+`/all-nric` requires a site in the query, so that one is checked before the read
+and answers `404` for a site the caller cannot reach — the same answer a site
+that does not exist gives, so ids cannot be probed.
+
+`/company` has no site or unit to scope on, so it is narrowed to the caller's
+own organisations — the fallback `getAll` already uses. `person.repo.getCompany`
+gains an optional `orgs` filter; absent means no restriction, which is what
+Seven365 staff get.
+
+`GET /user/:userId` also always answers about **your own** record, whatever your
+memberships say: the resident app reads it during sign-up and when resubmitting
+a rejected registration.

package/.changeset/person-search-filter-collision.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": patch
+---
+
+Make the people search filters narrow each other instead of overwriting each
+other.
+
+`person.repo.getAll` built its Mongo filter as one object literal in which four
+different filters each wrote a `$or` key — the date range (`dateTo`), the
+free-text `search`, `contact` and `plateNumber`. An object literal can only
+carry one `$or`, so the last one written silently replaced every earlier one.
+In practice:
+
+- searching by name **and** contact number searched only the contact number,
+- searching by name **and** plate number searched only the plate number,
+- and a **date range was dropped entirely** the moment any of the three was
+  used — which is the live case, because `layer-common`
+  `composables/usePeople.ts:2-30` sends `search`, `dateFrom` and `dateTo`
+  together from the visitor/people list.
+
+No error was raised; the endpoint simply answered a narrower question than it
+was asked, with rows that should not have matched.
+
+The four groups are now collected and combined with `$and`, so each one narrows
+the result. A single filter behaves exactly as before, and a request with no
+filters is unchanged.

package/.changeset/person-write-scope.md

@@ -0,0 +1,38 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the resident and visitor WRITES to a site the caller can actually reach.
+
+`PUT /api/people/id/:id` (edit), `PUT /api/people/:id` (delete),
+`PATCH /api/people/:id` (approve / reject / ask to resubmit) and the exported
+`suspendResidentById` identify the person by an id in the URL and carried
+`requireAuth` and nothing more. Any signed-in account on the platform — a
+resident, a cleaner, a guard at a different estate — could rename, delete,
+approve or reject any other client's resident. #1907 closed the read
+(`GET /api/people`); these are the writes behind it.
+
+The scope is resolved from the **stored record**, never from the request, and
+that is not a stylistic choice: **not one live caller sends a site.**
+`layer-common usePeople.deleteById` sends no body at all,
+`reviewResidentPerson` sends only `{ status, remarks }`, and both
+`web-app-property-management pages/[org]/[site]/people-mgmt/index.vue:915-917`
+and `components/PeopleFormMgmt.vue:618-620` explicitly `delete payload.site`
+before calling `updateById`. A guard that read the site out of the body would
+have refused every real caller and protected nobody.
+
+The rule is the site-reach rule the camera, HID and people-list already use —
+membership of the site, an org-wide membership at the site's owner, or an active
+`customer.sites` engagement — so an agency contracted to an estate keeps
+working. A record carrying an organisation but no site falls back to that
+organisation. Seven365 staff are unchanged.
+
+A resident resubmitting their own registration from the mobile app still works:
+`person.service.ts:155-166` writes a `members` row pinned to the site at
+sign-up, before any approval, so a rejected resident still reaches their own
+site. There is an end-to-end case for exactly that.
+
+Also: **who approved a resident now comes from the session.** It was read out of
+the `user` cookie the browser sends, falling back to whatever `approvedBy` the
+request body claimed, so an approval could be attributed to anybody. No caller
+sends `approvedBy`, so nothing is lost.

package/.changeset/role-scope-and-admin-type.md

@@ -0,0 +1,58 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope role writes to the role's own organisation, and reserve platform roles for Seven365 staff.
+
+Every write on `role.controller.ts` carried `requireAuth` and nothing more, and
+the role id comes from the URL. So any signed-in account on the platform — a
+resident, a cleaner, a guard — could reach any organisation's roles:
+
+- `PATCH /api/roles/permissions/id/:id` rewrote another client's role, including
+  its owner role. Executed against a throwaway database during the audit, an
+  outsider rewrote a second organisation's owner role and got a 200.
+- `PATCH /api/roles/id/:id` renamed it and replaced its permissions.
+- `PUT /api/roles/deleted/role` and `PUT /api/roles/:id/delete-with-reassignments`
+  deleted it, the second one moving its members onto other roles on the way.
+- `GET /api/roles/:id/deletion-preview` listed the members holding it — another
+  client's staff list by another name.
+- `POST /api/roles` and `POST /api/roles/v2` minted a role of `type: "admin"` —
+  the half of `isSuperAdmin` that lives in the roles collection.
+
+Each of the five writes now loads the role first and authorises on the
+organisation stored ON THAT ROLE, never on one the caller supplied:
+
+- a role carrying an `org` is a tenant's, and goes through `requireOrgAccess` —
+  Seven365 staff, or a live member of that organisation. That is the rule the
+  invitation and subscription paths already use; no new mechanism is introduced.
+- a role with NO `org` is a platform role — the staff console's own, and the one
+  `createDefaultUser` seeds — and only Seven365 staff may touch it. A missing org
+  is refused, not waved through.
+
+`createRole` on both `/api/roles` and `/api/roles/v2` requires the caller to be
+platform staff before it will accept `type: "admin"`. `/api/roles/v2` is a
+separate mount onto a separate controller, so gating one and not the other would
+have left the hole reachable by adding `/v2` to the URL.
+
+A role the caller may not reach is reported the same as a role that does not
+exist, so role ids cannot be enumerated by watching the difference.
+
+Two things are deliberately NOT changed, and are asserted in the tests so they
+read as decisions rather than oversights. `createRole` is not scoped to the
+caller's own organisation, and neither are the role reads: `web-app-main
+pages/sign-in.vue:311,439` and `pages/verify/email/index.vue:474` look up and
+create the "Admin Service Provider" role in the INVITING organisation, which the
+caller has not joined yet — that is what accepting a service-provider invitation
+is, and an org-membership check there would break sign-in for every invited
+provider. Scoping those needs the invitation to be consulted as well as the
+membership, and is a separate change.
+
+Every legitimate caller was checked and still works: the tenant screens
+(`web-app-org pages/org/[organization]/roles-permissions.vue`, and the
+`[org]/[site]/roles-permissions` screens in hygiene, security and
+property-management, all through `layer-common RolePermissionMain.vue` and
+`RolePermissionFormPreviewUpdate.vue`) edit roles in an organisation the operator
+is a member of; the staff console (`web-app-org pages/super-admin/*` and the
+retired admin app) is operated by staff and keeps cross-tenant reach.
+
+No response shape or field changed for a permitted caller.

package/.changeset/site-org-scope.md

@@ -0,0 +1,46 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `/api/sites` to the organisation that owns the site.
+
+Every route on this router except the pre-login resident picker carried
+`requireAuth` and nothing more (`site.controller.ts`), and took the
+organisation from the query string or the site id from the URL. `requireAuth`
+proves a session exists and makes no organisation or site decision, so any
+signed-in account on the platform — a resident, a cleaner, an agency guard —
+could `DELETE /api/sites/:id` any site belonging to any client, rename it,
+re-block it, move its guard posts, rewrite its information page, create a site
+inside any organisation, and page through any client's estate list.
+
+The caller is now resolved from the session and the decision made before
+anything is read or written:
+
+- `POST /` uses `requireOrgAccess` on the body's `orgId` — that is where the new
+  site lands.
+- `GET /` uses `requireOrgAccess` on the `org` filter the caller sends.
+- `PUT /:id/block`, `PATCH /id/:id`, `PATCH /guard-post/id/:id`,
+  `PATCH /information/id/:id` and `DELETE /:id` use `entitleSite` — 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: Site Settings lives in the SERVICE-PROVIDER apps
+  (`web-app-security` and the five module apps, each
+  `pages/[org]/[site]/settings.vue` via `layer-common useSiteSettings.ts`), and
+  those users hold no membership in the estate's organisation at all.
+- `GET /:id` is deliberately one notch wider than the writes: it also passes
+  for any live membership in the site's OWNING organisation. Three shipped
+  mobile clients read this route, and the resident app reads
+  `org.defaultSite` — which in a multi-site organisation need not be the
+  resident's own site, and a resident's membership carries a `siteId`. The
+  wider read closes the cross-CLIENT read, which is the defect, and leaves
+  site-to-site partitioning inside one client where it is today.
+
+A site the caller cannot reach answers exactly as a site that does not exist,
+so site ids cannot be enumerated by watching the difference.
+
+`GET /site/resident` is unchanged and still pre-login: the resident mobile app
+needs a site picker before an account exists.
+
+No new authorization mechanism is introduced — `requireOrgAccess` and
+`entitleSite` are the helpers the member, role, people, camera and HID paths
+already use.

package/.changeset/vehicle-approve-permission-prefix.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Check the vehicle-approval permission under the resource name the catalogues
+actually grant.
+
+When a security agency adds a vehicle, the vehicle is parked at `PENDING` unless
+the caller may approve one. `vehicle.service.ts:125` asked for
+`vehicleManagement:approve-vehicle`, but every catalogue that can grant a
+permission spells that resource `vehicle-mgmt` — `web-app-security`
+`composables/useSecurityPermission.ts:87,111`, `web-app-org`
+`composables/usePropertyPermission.ts:312`, `ma-mobile-app`
+`src/features/permissions/permission.catalog.ts:7`, `isecure365-mobile-app`
+`src/features/permissions/permission.catalog.ts:32`. Only the prefix differed,
+so the string checked here was one no role could hold and the bypass could never
+be reached by granting the permission — the agency's vehicles stayed pending
+however the role was set up. `vehicleManagement:` appears nowhere else in any
+repository in the organisation.
+
+The `*` wildcard branch is untouched, so a role holding all permissions behaves
+exactly as before; this only makes the specific grant work as intended.

package/.changeset/verification-status-transition.md

@@ -0,0 +1,35 @@
+---
+"@7365admin1/core": minor
+---
+
+Restrict the unauthenticated invitation-status write to the one transition its
+callers actually perform.
+
+`PATCH /api/auth/verification/status` (`API-core auth.route.ts:36`) carries no
+middleware, and it cannot be given any: every caller is an invitation-landing
+page opened from an emailed link **before an account exists** —
+`web-app-main` `pages/verify/invitation/[id].vue`,
+`pages/verify/service-provider/[id].vue`,
+`pages/verify/service-provider-invite/[id].vue` and
+`pages/sign-up-invite/service-provider/index.vue`, all through
+`layer-common composables/useLocalAuth.ts:130`. Adding `requireAuth` would break
+invitation acceptance for everybody, including the shipped clients.
+
+What is restricted instead is what an anonymous caller may *do*. Each of those
+pages calls `GET /auth/verify/:id` first, and `verify`
+(`verification.service.ts:661-690`) already refuses an invitation that is
+expired, cancelled or complete — so the only transition a real caller ever
+performs is `pending -> complete`. Accepting the other three states let anyone
+who learned an invitation id:
+
+- set a used invitation back to `pending` and replay it,
+- revive a `cancelled` or `expired` invitation, or
+- burn somebody else's pending invitation by marking it `complete` before they
+  opened the email.
+
+The handler now accepts only `complete`, loads the invitation and requires it to
+be `pending`. Completing an already-complete invitation still answers 200 so a
+page that calls this twice is not broken. Cancelling an invitation on purpose
+keeps its own session-protected endpoint,
+`PUT /api/verifications/:id/cancel` (`verification.route.ts:13`), so no
+capability is removed.