@7365admin1/core 3.49.1-staging.214 → 3.50.0

package/CHANGELOG.md

@@ -1,5 +1,343 @@
 # @iservice365/core
 
+## 3.50.0
+
+### Minor Changes
+
+- ee5e7dd: Scope the access-management routes that name a card, not a site.
+
+  `access-management-site-scope` closed the routes whose request already carries
+  an estate. Seven routes on the same mount carry none — they reach an access card
+  (or a unit) by `_id` and nothing else — so there was nothing for that rule to
+  read and they were left carrying `requireAuth` alone:
+
+  - `POST /sign-qr` — mints a working door credential. The card number is
+    RSA-encrypted into a QR payload the reader accepts for up to 24 hours when
+    `purpose` is `"vms"`. Any signed-in account could hand itself a valid pass for
+    any card in any estate on the platform.
+  - `PATCH /delete-card` — deactivates a card, which is what stops it opening a
+    door.
+  - `PATCH /nfc-status` — flips a card's status and activation.
+  - `PATCH /visitor-checkout` — releases a visitor's card and writes its history.
+  - `POST /card-replacement` — retires a card and hands its replacement to a unit.
+  - `POST /assign-user` — hands the cards on a unit to a list of people.
+  - `POST /settings` — rewrites an estate's access-management settings, including
+    the address of the Entrypass controller it talks to. This one DOES carry the
+    estate, in the body, and the repository upserts on it; it was simply never
+    checked.
+
+  For the six that name a record, the scope is now decided on the STORED row via
+  `siteReachOf` — the same rule `requireBulletinVideoReach` and
+  `requireEntryPassReach` already apply, and the same underlying `entitleSite`
+  verdict as `requireSiteReach`. `POST /settings` uses `requireSiteReach` on the
+  body's site, exactly as `GET /settings/:site` already does. No new mechanism and
+  no new permission string: reaching the estate is the whole rule, so the
+  contracted agency at the guardhouse, the org-wide manager and a resident reading
+  their own pass are all unaffected.
+
+  Where a write MOVES a card onto a unit (`card-replacement`, `assign-user`) the
+  destination unit is checked as well as the card, so a card cannot be re-parented
+  into an estate the caller cannot reach.
+
+  "Not yours" and "does not exist" answer identically (404), so card ids cannot be
+  enumerated. An id matching no row is refused rather than waved through, and a
+  row naming no estate fails closed. The guards sit after each handler's Joi
+  validation, so malformed input still answers 400 exactly as before.
+
+  `GET /door-access-levels`, `GET /lift-access-levels` and `GET /access-groups`
+  are deliberately NOT changed: they carry no estate and no record, only a
+  caller-supplied `acm_url`, so there is nothing to scope against without changing
+  their request contract. They are recorded as a separate piece of work.
+
+- 042aae6: Scope invitation creation to an organisation the caller can reach, and stop a
+  non-staff caller minting a Seven365 staff invitation on the v1 endpoints.
+
+  Six endpoints took `metadata.org` — and the `app` that becomes the accepted
+  membership's `type` — straight from the request body, behind `requireAuth` and
+  nothing else:
+
+  - `POST /api/auth/invite` (`auth.route.ts:29`)
+  - `POST /api/auth/invite/user` (`auth.route.ts:30`)
+  - `POST /api/auth/invite/member` (`auth.route.ts:31`)
+  - `POST /api/auth/invite/service-provider/with-org` (`auth.route.ts:33`)
+  - `POST /api/auth/v2/invite` (`auth-v2.route.ts:22`)
+  - `POST /api/auth/v2/invite/organization` (`auth-v2.route.ts:23`)
+
+  Two things followed from that.
+
+  **The organisation.** The roles/members fix lets somebody holding an invitation
+  into an organisation reach it, because the client onboarding wizard needs that.
+  An attacker could therefore issue themselves the invitation the gate asks for —
+  one authenticated write naming any victim organisation — and walk straight back
+  into the chain that fix closed.
+
+  **`app`.** "admin" is what makes a membership Seven365 staff, and
+  `member.service.ts acceptInvite` writes `type: invite.metadata.app` verbatim.
+  `createMemberDirect` already refuses a staff membership from a non-staff caller;
+  the invitation road to the same place was open on the v1 mounts. The v2 twin
+  asked; the v1 mounts, which are the ones the web apps call, did not.
+
+  All six now call `requireInviteReach` (`utils/console-authz.util.ts`): Seven365
+  staff, a live member of the organisation, or somebody holding an invitation into
+  it — plus `requirePlatformStaff` when the invitation names the staff app. An
+  invitation that names no organisation is unchanged; it grants no organisation,
+  exactly as an org-less `GET /api/roles` does. The two service-provider invites
+  that already resolved their caller from the session are unchanged.
+
+- dc7ab90: Scope the organisation list to the caller, and put the promo-code list behind the staff gate.
+
+  `GET /api/organizations` and `GET /api/promo-codes` performed no authorization
+  at all — `requireAuth` and nothing more — while every sibling handler in the
+  same two files guarded. So any signed-in account on the platform, a resident or
+  a cleaner included, could page through the name, e-mail, nature and status of
+  **every Seven365 client**, and read off **every discount code** we have ever
+  minted, with its rate and its expiry, and then redeem whichever is worth most.
+
+  The two rules are different, because the callers are different.
+
+  **`GET /api/organizations` is now a SCOPE, not a refusal.** Seven365 staff see
+  every organisation exactly as before; anybody else sees the organisations they
+  hold a live membership of, plus any registered under their own verified account
+  e-mail. The e-mail half is not decoration: `web-app-main
+pages/verify/email/index.vue:322` — the org-owner self-signup — lists
+  organisations to find the one it created a line earlier, at which point that
+  brand-new client owner is a member of nothing. Refusing them would have traded
+  the leak for a broken signup. The comparison is the one
+  `getOrgsByEmail` already makes, against the address on the caller's own `users`
+  row; nothing the caller sends takes part in it. It also removes a real bug from
+  that flow: the page takes `items[0]` of a newest-first list, so two client
+  owners signing up in the same moment could be handed each other's organisation
+  as their `defaultOrg`.
+
+  The scope is part of the Redis cache key as well as the query, so one caller's
+  narrowed page is never replayed to the next, and `countDocuments` runs the
+  scoped query so pagination cannot walk past the scope.
+
+  **`GET /api/promo-codes` is Seven365 staff only,** together with
+  `GET /api/promo-codes/id/:id`, which is the same disclosure one record at a
+  time. Both are read solely by the staff console. A client at checkout is
+  unaffected: `web-app-org pages/checkout.vue` and
+  `subscription/manage-seats.vue` type a code and validate it through
+  `GET /api/promo-codes/code`, which stays signed-in-only and is untouched.
+
+- c7b57f5: Make revoking somebody's access actually end their session.
+
+  A session in this product is an opaque `sid` whose only record of truth is a
+  Redis key `sid:<sid>` holding a copy of the user document. `requireAuth`
+  authenticates a request by finding that key and nothing else — it never reads
+  the database — and it re-`EXPIRE`s the key to four hours on every request, so a
+  session that is in use never ages out on its own.
+
+  **Signing out was never the problem.** `logout()` deletes the key, so a
+  signed-out session is refused; that half already worked. Every other way access
+  is taken away did not.
+
+  **Suspending somebody changed a column and nothing else.**
+  `suspendResidentById` writes `users.status = "suspended"` through
+  `updateUserFieldById`, which cleared the user-document cache and left the
+  `sid:` key untouched. The person carried on working, and every request they made
+  pushed the four-hour expiry out another four hours. On top of that,
+  `refreshToken()` minted a **brand new** session through `issueSession` with no
+  account-status check at all — the mobile refresh token is seven days and
+  rotating, so a suspended account's phone could keep issuing itself fresh
+  sessions indefinitely. Suspension was not a delay, it was a no-op for anyone
+  already signed in.
+
+  **Two of the statuses the product writes were never refused at sign-in either.**
+  Both `login()`s checked `suspended` and `pending` only, so `rejected` (written by
+  `reviewPerson`, whose email is the one that hides the login link) and `deleted`
+  (`UserStatus.DELETED`, the soft-delete marker) could sign in fresh with a
+  password.
+
+  The fix is the two halves of that, at the two choke points that already exist:
+
+  - **Minting refuses a non-live account** — `assertAccountLive` in `issueSession`
+    in both auth services, which is the one place every sign-in path in this
+    package goes through (login and mobile refresh, v1 and v2), for the same
+    reason `assertOrganizationNotSuspended` lives there.
+  - **Revoking destroys what already exists** — `revokeAccountAccess` from
+    `updateUserFieldById`, the only path in either user repository that writes
+    `users.status`. It deletes every `sid:` key the person holds and every refresh
+    token in `tokens`, so nothing can mint a replacement.
+
+  Finding every session a person holds needs an index: `users.sid` only ever
+  remembers the most recent sign-in, v2 never writes it, and nothing reads it — a
+  fix built on that column would revoke the phone and leave the browser signed in.
+  The index is a Redis set (`user-sessions:<userId>`), so there is no schema
+  change and no migration; `users.sid` stays as the fallback that catches v1
+  sessions minted before the set existed.
+
+  The blocking statuses are `suspended`, `pending`, `rejected` and `deleted`, as a
+  deny-list — `status` is optional on the model and legacy rows carry `""` or no
+  field at all, and an allow-list would lock every one of them out. `resubmit` is
+  deliberately live: that email keeps the login link, because resubmitting the
+  application is done signed in.
+
+  Nothing is logged out by deploying this — no existing session is touched, and
+  the two sign-in messages for `suspended` and `pending` are unchanged, because
+  `login()` still checks those two itself before minting. What changes for a
+  signed-in user is only that a `rejected` or soft-deleted account can no longer
+  obtain a session, and that a suspension now takes effect at once rather than
+  never.
+
+- 6cbc3fa: Stop a deleted role from conferring Seven365 identity, and protect the seeded
+  platform-owner role.
+
+  Two defects on the roles collection, both of which made an ordinary
+  administrative action do the opposite of what it says.
+
+  **Deleting somebody's admin role did not take their access away.**
+  `deleteRole` (`role.repo.ts`) is a SOFT delete: it sets `{ status: "deleted" }`
+  and leaves the document in place. `isSuperAdmin` and `isPlatformOwner`
+  (`super-admin.util.ts`) read that role by `_id` alone, and so did the second
+  staff derivation in `resolveInviteActor` (`invite-actor.util.ts`). So the
+  ordinary way to revoke a Seven365 staff account — delete the admin role it sits
+  on — left the account platform staff: `requirePlatformStaff` still passed, and
+  staff identity is the bypass on `requireOrgAccess`, on `requireSiteReach` and on
+  organisation suspension. `getUserPermissions` (`permission.util.ts`) always
+  filtered on status, which is why the same account lost every permission and kept
+  the identity that makes permissions unnecessary.
+
+  All three identity derivations now require a live role. "Live" is spelled
+  `$ne: "deleted"` — the test already applied to the `members` row in the same
+  functions — rather than `status: "active"`. Roles carry exactly two statuses in
+  this package: `MRole` has defaulted `status` to `"active"` since the model's
+  first commit and every insert goes through `addRole` -> `new MRole()`, and
+  `"deleted"` is written by `deleteRole` alone (no API can send `status` on a
+  role; `updateRole` takes a name and permissions only). The two spellings
+  therefore agree on every row this package can write and differ only on a
+  pre-package row carrying no `status` at all, where `$ne` keeps that account
+  working and `"active"` would silently strip its console access. No migration is
+  implied.
+
+  **The seeded platform-owner role could be deleted, and nothing put it back.**
+  `createDefaultUser()` seeds one org-less `{ type: "admin", default: true }`
+  role, and that pair is the whole of `isPlatformOwner`. Deleting it is a one-way
+  door: `getRoles` lists active rows only, so it disappears from the roles screen,
+  and at the next boot `createDefaultUser` finds the deleted row by name and type
+  and reuses it rather than seeding a fresh one — leaving the owner account with
+  no permissions and no way to restore the role through the product. The Delete
+  and Edit buttons on the roles screen
+  (`layer-common components/RolePermissionMain.vue`) both reached it.
+
+  `role.repo.ts` now refuses to delete, rename or rewrite the permissions of that
+  role. The guard sits in the repository because all four write paths pass through
+  those three functions: `role.service.deleteRole`,
+  `role.service.deleteWithReassignments` (which deletes inside a transaction after
+  moving every member off), and the two `role.controller` edit paths that call the
+  repository directly — a guard in the service would have covered the deletes and
+  missed the edits. A CLIENT's own "owner" role is also `default: true`
+  (`subscription.service` writes two per new client) but is typed `organization`
+  or the org's nature, so requiring the platform staff type leaves every client's
+  own role editable exactly as before.
+
+  No new authorization mechanism is introduced, and no route's authentication or
+  permission requirements change.
+
+- ebdfd23: Scope the role list, role creation and direct membership creation to an
+  organisation the caller can actually reach.
+
+  Two endpoints took the organisation straight from the request, and they chained
+  into a cross-tenant escalation that any signed-in account could run:
+
+  1. `GET /api/roles?org=<any org id>` listed that client's roles with their ids —
+     `role.controller.ts getRoles` made no scope call at all and `role.repo.ts`
+     put the caller's query string into `{ status: "active", org }`.
+  2. `POST /api/members/direct` wrote a membership into whatever `orgId` the body
+     named (`member.controller.ts createMemberDirect` validated the shape and
+     nothing else).
+  3. `member.model.ts` writes `status: value.status || "active"`, so that row is
+     live on insert.
+  4. `resolveInviteActor` then reports that organisation in the caller's `orgIds`,
+     which is exactly what `requireOrgAccess` asks for — the gate that every
+     role, member, people, site and camera fix in the 3.49.0 wave depends on.
+
+  So a resident, a visitor's contact or a cleaner could enrol itself as an active
+  member of any client organisation and inherit that client's reach. The
+  escalation to Seven365 platform owner was closed earlier; this is the same
+  attack scoped down one level, at the tenant.
+
+  The decision is a new `requireOrgReach` in `console-authz.util.ts`: **Seven365
+  staff, a live member of the organisation, or somebody holding an invitation into
+  it.** The third clause is not a convenience — three live flows legitimately
+  reach an organisation before any membership exists, and a flat membership test
+  would break all of them:
+
+  - the service provider signing in against a `service-provider-invite`, who looks
+    up the customer's "Admin Service Provider" role and creates it when the
+    customer has none (`web-app-main pages/sign-in.vue:298,311,428`);
+  - the admin member finishing sign-up from a `member-invite`
+    (`web-app-main pages/verify/email/index.vue:462`);
+  - the client owner walking the onboarding wizard
+    (`web-app-org pages/onboarding/getting-started/index.vue`).
+
+  All three hold a verification addressed to their own email whose `metadata.org`
+  is the organisation being reached, and that invitation is the relationship the
+  rule tests (`hasOrgInvitation` in `invite-actor.util.ts`). The address is read
+  from the `users` row for the session id, never from the request; both the
+  ObjectId and the older string shape of `metadata.org` are matched, the same pair
+  `completePendingInvites` matches on; and only the three invitation types count,
+  so a password-reset code opens nothing.
+
+  Where the check now runs:
+
+  - `GET /api/roles` — when the caller sends an `org`. With no `org` the query is
+    unchanged and still matches only the ORG-LESS platform roles, which is what
+    every invitation screen asks for and is not a tenant's data.
+  - `POST /api/roles` and `POST /api/roles/v2` — on the `org` the new role is
+    filed under. Both mounts, because `/v2` is a separate controller and gating
+    one would leave the hole reachable by adding `/v2` to the URL.
+  - `POST /api/members/direct` — enrolling YOURSELF needs reach, so an invitation
+    counts; enrolling ANYBODY ELSE needs `requireOrgAccess`, real membership. The
+    onboarding wizard's second call, which adds the Seven365 support account,
+    always follows the caller's own row, so it passes.
+
+  `requireOrgAccess` itself is untouched. The invitation clause is additive and
+  lives in a separate function — widening the shared one would hand all 78 of its
+  mounts to anybody holding an invitation.
+
+  Proved end to end in `test/e2e/org-scoping-roles-members.e2e.test.mjs`: 13 of
+  its 23 cases fail on the code before this change and all 23 pass after, while
+  every "must keep working" case — the caller's own org, the org-less platform
+  list, a member enrolling a colleague, staff reaching any client, and the whole
+  invited-newcomer flow — passes on both.
+
+### Patch Changes
+
+- 7bf8130: Decide the HRM Labs location server-side, so an entitled caller cannot read
+  another site's roster.
+
+  `requireSiteReach(req, siteId, ATTENDANCE_READ)` guards all four manpower-attendance
+  reads, but `siteId` is not what selects the roster — it only picks the local
+  `manpower-settings` row. The roster is selected by `locationName`, the field HRM Labs
+  is asked for, and that came straight from the request body's `siteName` with nothing
+  checking it against `siteId`.
+
+  So the two could disagree. A caller entitled to site A could send site A's `siteId`,
+  pass the guard, and pair it with **another** site's `siteName` — and read that site's
+  employee roster back: names, staff numbers, job titles, NRICs
+  (`identificationNumber`) and the check-in/check-out photographs. The exposure had been
+  narrowed from anyone on the internet to any signed-in account; this closes it.
+
+  The location now comes from `config.siteName`, the settings row the caller was already
+  entitled to, via one `locationOf()` helper called in each of the four functions. That
+  is the same source the screen reads from: the security app fills `siteId` and
+  `siteName` from one HRM Labs site-list entry (`site.id` / `site.text`),
+  `manpowerMonitoringSchema` makes `siteName` required on both write paths, and
+  `TManpowerMonitoringUpdate` cannot change it — so for every legitimate row the pair
+  already agreed and the server simply stops asking.
+
+  A row with no stored name is refused rather than falling back to the body; a fallback
+  would re-open the hole for exactly the rows an attacker would want to name for
+  themselves.
+
+  Nothing legitimate changes. The Joi schemas still accept `siteName`, so no client needs
+  a coordinated release — it is accepted and ignored. The three internal callers
+  (`manpower.event.ts` and the two `cron.util.ts` sweeps) get more reliable, not less:
+  they were passing `manpower-remarks.siteName`, which that model marks optional.
+
+- 0be47d5: Scope the "my memberships" reads and the preloved marketplace to the record's stored owner.
+
 ## 3.49.0
 
 ### Minor Changes

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@7365admin1/core",
   "license": "MIT",
-  "version": "3.49.1-staging.214",
+  "version": "3.50.0",
   "author": "7365admin1",
   "main": "dist/index.js",
   "module": "dist/index.mjs",

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

@@ -1,48 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Scope the access-management routes that name a card, not a site.
-
-`access-management-site-scope` closed the routes whose request already carries
-an estate. Seven routes on the same mount carry none — they reach an access card
-(or a unit) by `_id` and nothing else — so there was nothing for that rule to
-read and they were left carrying `requireAuth` alone:
-
-- `POST /sign-qr` — mints a working door credential. The card number is
-  RSA-encrypted into a QR payload the reader accepts for up to 24 hours when
-  `purpose` is `"vms"`. Any signed-in account could hand itself a valid pass for
-  any card in any estate on the platform.
-- `PATCH /delete-card` — deactivates a card, which is what stops it opening a
-  door.
-- `PATCH /nfc-status` — flips a card's status and activation.
-- `PATCH /visitor-checkout` — releases a visitor's card and writes its history.
-- `POST /card-replacement` — retires a card and hands its replacement to a unit.
-- `POST /assign-user` — hands the cards on a unit to a list of people.
-- `POST /settings` — rewrites an estate's access-management settings, including
-  the address of the Entrypass controller it talks to. This one DOES carry the
-  estate, in the body, and the repository upserts on it; it was simply never
-  checked.
-
-For the six that name a record, the scope is now decided on the STORED row via
-`siteReachOf` — the same rule `requireBulletinVideoReach` and
-`requireEntryPassReach` already apply, and the same underlying `entitleSite`
-verdict as `requireSiteReach`. `POST /settings` uses `requireSiteReach` on the
-body's site, exactly as `GET /settings/:site` already does. No new mechanism and
-no new permission string: reaching the estate is the whole rule, so the
-contracted agency at the guardhouse, the org-wide manager and a resident reading
-their own pass are all unaffected.
-
-Where a write MOVES a card onto a unit (`card-replacement`, `assign-user`) the
-destination unit is checked as well as the card, so a card cannot be re-parented
-into an estate the caller cannot reach.
-
-"Not yours" and "does not exist" answer identically (404), so card ids cannot be
-enumerated. An id matching no row is refused rather than waved through, and a
-row naming no estate fails closed. The guards sit after each handler's Joi
-validation, so malformed input still answers 400 exactly as before.
-
-`GET /door-access-levels`, `GET /lift-access-levels` and `GET /access-groups`
-are deliberately NOT changed: they carry no estate and no record, only a
-caller-supplied `acm_url`, so there is nothing to scope against without changing
-their request contract. They are recorded as a separate piece of work.

package/.changeset/hrmlabs-attendance-location-name.md

@@ -1,35 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Decide the HRM Labs location server-side, so an entitled caller cannot read
-another site's roster.
-
-`requireSiteReach(req, siteId, ATTENDANCE_READ)` guards all four manpower-attendance
-reads, but `siteId` is not what selects the roster — it only picks the local
-`manpower-settings` row. The roster is selected by `locationName`, the field HRM Labs
-is asked for, and that came straight from the request body's `siteName` with nothing
-checking it against `siteId`.
-
-So the two could disagree. A caller entitled to site A could send site A's `siteId`,
-pass the guard, and pair it with **another** site's `siteName` — and read that site's
-employee roster back: names, staff numbers, job titles, NRICs
-(`identificationNumber`) and the check-in/check-out photographs. The exposure had been
-narrowed from anyone on the internet to any signed-in account; this closes it.
-
-The location now comes from `config.siteName`, the settings row the caller was already
-entitled to, via one `locationOf()` helper called in each of the four functions. That
-is the same source the screen reads from: the security app fills `siteId` and
-`siteName` from one HRM Labs site-list entry (`site.id` / `site.text`),
-`manpowerMonitoringSchema` makes `siteName` required on both write paths, and
-`TManpowerMonitoringUpdate` cannot change it — so for every legitimate row the pair
-already agreed and the server simply stops asking.
-
-A row with no stored name is refused rather than falling back to the body; a fallback
-would re-open the hole for exactly the rows an attacker would want to name for
-themselves.
-
-Nothing legitimate changes. The Joi schemas still accept `siteName`, so no client needs
-a coordinated release — it is accepted and ignored. The three internal callers
-(`manpower.event.ts` and the two `cron.util.ts` sweeps) get more reliable, not less:
-they were passing `manpower-remarks.siteName`, which that model marks optional.

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

@@ -1,38 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Scope invitation creation to an organisation the caller can reach, and stop a
-non-staff caller minting a Seven365 staff invitation on the v1 endpoints.
-
-Six endpoints took `metadata.org` — and the `app` that becomes the accepted
-membership's `type` — straight from the request body, behind `requireAuth` and
-nothing else:
-
-- `POST /api/auth/invite` (`auth.route.ts:29`)
-- `POST /api/auth/invite/user` (`auth.route.ts:30`)
-- `POST /api/auth/invite/member` (`auth.route.ts:31`)
-- `POST /api/auth/invite/service-provider/with-org` (`auth.route.ts:33`)
-- `POST /api/auth/v2/invite` (`auth-v2.route.ts:22`)
-- `POST /api/auth/v2/invite/organization` (`auth-v2.route.ts:23`)
-
-Two things followed from that.
-
-**The organisation.** The roles/members fix lets somebody holding an invitation
-into an organisation reach it, because the client onboarding wizard needs that.
-An attacker could therefore issue themselves the invitation the gate asks for —
-one authenticated write naming any victim organisation — and walk straight back
-into the chain that fix closed.
-
-**`app`.** "admin" is what makes a membership Seven365 staff, and
-`member.service.ts acceptInvite` writes `type: invite.metadata.app` verbatim.
-`createMemberDirect` already refuses a staff membership from a non-staff caller;
-the invitation road to the same place was open on the v1 mounts. The v2 twin
-asked; the v1 mounts, which are the ones the web apps call, did not.
-
-All six now call `requireInviteReach` (`utils/console-authz.util.ts`): Seven365
-staff, a live member of the organisation, or somebody holding an invitation into
-it — plus `requirePlatformStaff` when the invitation names the staff app. An
-invitation that names no organisation is unchanged; it grants no organisation,
-exactly as an org-less `GET /api/roles` does. The two service-provider invites
-that already resolved their caller from the session are unchanged.

package/.changeset/organization-and-promo-list-scope.md

@@ -1,39 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Scope the organisation list to the caller, and put the promo-code list behind the staff gate.
-
-`GET /api/organizations` and `GET /api/promo-codes` performed no authorization
-at all — `requireAuth` and nothing more — while every sibling handler in the
-same two files guarded. So any signed-in account on the platform, a resident or
-a cleaner included, could page through the name, e-mail, nature and status of
-**every Seven365 client**, and read off **every discount code** we have ever
-minted, with its rate and its expiry, and then redeem whichever is worth most.
-
-The two rules are different, because the callers are different.
-
-**`GET /api/organizations` is now a SCOPE, not a refusal.** Seven365 staff see
-every organisation exactly as before; anybody else sees the organisations they
-hold a live membership of, plus any registered under their own verified account
-e-mail. The e-mail half is not decoration: `web-app-main
-pages/verify/email/index.vue:322` — the org-owner self-signup — lists
-organisations to find the one it created a line earlier, at which point that
-brand-new client owner is a member of nothing. Refusing them would have traded
-the leak for a broken signup. The comparison is the one
-`getOrgsByEmail` already makes, against the address on the caller's own `users`
-row; nothing the caller sends takes part in it. It also removes a real bug from
-that flow: the page takes `items[0]` of a newest-first list, so two client
-owners signing up in the same moment could be handed each other's organisation
-as their `defaultOrg`.
-
-The scope is part of the Redis cache key as well as the query, so one caller's
-narrowed page is never replayed to the next, and `countDocuments` runs the
-scoped query so pagination cannot walk past the scope.
-
-**`GET /api/promo-codes` is Seven365 staff only,** together with
-`GET /api/promo-codes/id/:id`, which is the same disclosure one record at a
-time. Both are read solely by the staff console. A client at checkout is
-unaffected: `web-app-org pages/checkout.vue` and
-`subscription/manage-seats.vue` type a code and validate it through
-`GET /api/promo-codes/code`, which stays signed-in-only and is untouched.

package/.changeset/resident-ownership-scope.md

@@ -1,5 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Scope the "my memberships" reads and the preloved marketplace to the record's stored owner.

package/.changeset/revoke-sessions-when-access-is-taken-away.md

@@ -1,63 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Make revoking somebody's access actually end their session.
-
-A session in this product is an opaque `sid` whose only record of truth is a
-Redis key `sid:<sid>` holding a copy of the user document. `requireAuth`
-authenticates a request by finding that key and nothing else — it never reads
-the database — and it re-`EXPIRE`s the key to four hours on every request, so a
-session that is in use never ages out on its own.
-
-**Signing out was never the problem.** `logout()` deletes the key, so a
-signed-out session is refused; that half already worked. Every other way access
-is taken away did not.
-
-**Suspending somebody changed a column and nothing else.**
-`suspendResidentById` writes `users.status = "suspended"` through
-`updateUserFieldById`, which cleared the user-document cache and left the
-`sid:` key untouched. The person carried on working, and every request they made
-pushed the four-hour expiry out another four hours. On top of that,
-`refreshToken()` minted a **brand new** session through `issueSession` with no
-account-status check at all — the mobile refresh token is seven days and
-rotating, so a suspended account's phone could keep issuing itself fresh
-sessions indefinitely. Suspension was not a delay, it was a no-op for anyone
-already signed in.
-
-**Two of the statuses the product writes were never refused at sign-in either.**
-Both `login()`s checked `suspended` and `pending` only, so `rejected` (written by
-`reviewPerson`, whose email is the one that hides the login link) and `deleted`
-(`UserStatus.DELETED`, the soft-delete marker) could sign in fresh with a
-password.
-
-The fix is the two halves of that, at the two choke points that already exist:
-
-- **Minting refuses a non-live account** — `assertAccountLive` in `issueSession`
-  in both auth services, which is the one place every sign-in path in this
-  package goes through (login and mobile refresh, v1 and v2), for the same
-  reason `assertOrganizationNotSuspended` lives there.
-- **Revoking destroys what already exists** — `revokeAccountAccess` from
-  `updateUserFieldById`, the only path in either user repository that writes
-  `users.status`. It deletes every `sid:` key the person holds and every refresh
-  token in `tokens`, so nothing can mint a replacement.
-
-Finding every session a person holds needs an index: `users.sid` only ever
-remembers the most recent sign-in, v2 never writes it, and nothing reads it — a
-fix built on that column would revoke the phone and leave the browser signed in.
-The index is a Redis set (`user-sessions:<userId>`), so there is no schema
-change and no migration; `users.sid` stays as the fallback that catches v1
-sessions minted before the set existed.
-
-The blocking statuses are `suspended`, `pending`, `rejected` and `deleted`, as a
-deny-list — `status` is optional on the model and legacy rows carry `""` or no
-field at all, and an allow-list would lock every one of them out. `resubmit` is
-deliberately live: that email keeps the login link, because resubmitting the
-application is done signed in.
-
-Nothing is logged out by deploying this — no existing session is touched, and
-the two sign-in messages for `suspended` and `pending` are unchanged, because
-`login()` still checks those two itself before minting. What changes for a
-signed-in user is only that a `rejected` or soft-deleted account can no longer
-obtain a session, and that a suspension now takes effect at once rather than
-never.

package/.changeset/role-identity-status-and-seeded-role.md

@@ -1,57 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Stop a deleted role from conferring Seven365 identity, and protect the seeded
-platform-owner role.
-
-Two defects on the roles collection, both of which made an ordinary
-administrative action do the opposite of what it says.
-
-**Deleting somebody's admin role did not take their access away.**
-`deleteRole` (`role.repo.ts`) is a SOFT delete: it sets `{ status: "deleted" }`
-and leaves the document in place. `isSuperAdmin` and `isPlatformOwner`
-(`super-admin.util.ts`) read that role by `_id` alone, and so did the second
-staff derivation in `resolveInviteActor` (`invite-actor.util.ts`). So the
-ordinary way to revoke a Seven365 staff account — delete the admin role it sits
-on — left the account platform staff: `requirePlatformStaff` still passed, and
-staff identity is the bypass on `requireOrgAccess`, on `requireSiteReach` and on
-organisation suspension. `getUserPermissions` (`permission.util.ts`) always
-filtered on status, which is why the same account lost every permission and kept
-the identity that makes permissions unnecessary.
-
-All three identity derivations now require a live role. "Live" is spelled
-`$ne: "deleted"` — the test already applied to the `members` row in the same
-functions — rather than `status: "active"`. Roles carry exactly two statuses in
-this package: `MRole` has defaulted `status` to `"active"` since the model's
-first commit and every insert goes through `addRole` -> `new MRole()`, and
-`"deleted"` is written by `deleteRole` alone (no API can send `status` on a
-role; `updateRole` takes a name and permissions only). The two spellings
-therefore agree on every row this package can write and differ only on a
-pre-package row carrying no `status` at all, where `$ne` keeps that account
-working and `"active"` would silently strip its console access. No migration is
-implied.
-
-**The seeded platform-owner role could be deleted, and nothing put it back.**
-`createDefaultUser()` seeds one org-less `{ type: "admin", default: true }`
-role, and that pair is the whole of `isPlatformOwner`. Deleting it is a one-way
-door: `getRoles` lists active rows only, so it disappears from the roles screen,
-and at the next boot `createDefaultUser` finds the deleted row by name and type
-and reuses it rather than seeding a fresh one — leaving the owner account with
-no permissions and no way to restore the role through the product. The Delete
-and Edit buttons on the roles screen
-(`layer-common components/RolePermissionMain.vue`) both reached it.
-
-`role.repo.ts` now refuses to delete, rename or rewrite the permissions of that
-role. The guard sits in the repository because all four write paths pass through
-those three functions: `role.service.deleteRole`,
-`role.service.deleteWithReassignments` (which deletes inside a transaction after
-moving every member off), and the two `role.controller` edit paths that call the
-repository directly — a guard in the service would have covered the deletes and
-missed the edits. A CLIENT's own "owner" role is also `default: true`
-(`subscription.service` writes two per new client) but is typed `organization`
-or the org's nature, so requiring the platform staff type leaves every client's
-own role editable exactly as before.
-
-No new authorization mechanism is introduced, and no route's authentication or
-permission requirements change.

package/.changeset/role-member-org-scope.md

@@ -1,71 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Scope the role list, role creation and direct membership creation to an
-organisation the caller can actually reach.
-
-Two endpoints took the organisation straight from the request, and they chained
-into a cross-tenant escalation that any signed-in account could run:
-
-1. `GET /api/roles?org=<any org id>` listed that client's roles with their ids —
-   `role.controller.ts getRoles` made no scope call at all and `role.repo.ts`
-   put the caller's query string into `{ status: "active", org }`.
-2. `POST /api/members/direct` wrote a membership into whatever `orgId` the body
-   named (`member.controller.ts createMemberDirect` validated the shape and
-   nothing else).
-3. `member.model.ts` writes `status: value.status || "active"`, so that row is
-   live on insert.
-4. `resolveInviteActor` then reports that organisation in the caller's `orgIds`,
-   which is exactly what `requireOrgAccess` asks for — the gate that every
-   role, member, people, site and camera fix in the 3.49.0 wave depends on.
-
-So a resident, a visitor's contact or a cleaner could enrol itself as an active
-member of any client organisation and inherit that client's reach. The
-escalation to Seven365 platform owner was closed earlier; this is the same
-attack scoped down one level, at the tenant.
-
-The decision is a new `requireOrgReach` in `console-authz.util.ts`: **Seven365
-staff, a live member of the organisation, or somebody holding an invitation into
-it.** The third clause is not a convenience — three live flows legitimately
-reach an organisation before any membership exists, and a flat membership test
-would break all of them:
-
-- the service provider signing in against a `service-provider-invite`, who looks
-  up the customer's "Admin Service Provider" role and creates it when the
-  customer has none (`web-app-main pages/sign-in.vue:298,311,428`);
-- the admin member finishing sign-up from a `member-invite`
-  (`web-app-main pages/verify/email/index.vue:462`);
-- the client owner walking the onboarding wizard
-  (`web-app-org pages/onboarding/getting-started/index.vue`).
-
-All three hold a verification addressed to their own email whose `metadata.org`
-is the organisation being reached, and that invitation is the relationship the
-rule tests (`hasOrgInvitation` in `invite-actor.util.ts`). The address is read
-from the `users` row for the session id, never from the request; both the
-ObjectId and the older string shape of `metadata.org` are matched, the same pair
-`completePendingInvites` matches on; and only the three invitation types count,
-so a password-reset code opens nothing.
-
-Where the check now runs:
-
-- `GET /api/roles` — when the caller sends an `org`. With no `org` the query is
-  unchanged and still matches only the ORG-LESS platform roles, which is what
-  every invitation screen asks for and is not a tenant's data.
-- `POST /api/roles` and `POST /api/roles/v2` — on the `org` the new role is
-  filed under. Both mounts, because `/v2` is a separate controller and gating
-  one would leave the hole reachable by adding `/v2` to the URL.
-- `POST /api/members/direct` — enrolling YOURSELF needs reach, so an invitation
-  counts; enrolling ANYBODY ELSE needs `requireOrgAccess`, real membership. The
-  onboarding wizard's second call, which adds the Seven365 support account,
-  always follows the caller's own row, so it passes.
-
-`requireOrgAccess` itself is untouched. The invitation clause is additive and
-lives in a separate function — widening the shared one would hand all 78 of its
-mounts to anybody holding an invitation.
-
-Proved end to end in `test/e2e/org-scoping-roles-members.e2e.test.mjs`: 13 of
-its 23 cases fail on the code before this change and all 23 pass after, while
-every "must keep working" case — the caller's own org, the org-less platform
-list, a member enrolling a colleague, staff reaching any client, and the whole
-invited-newcomer flow — passes on both.