@7365admin1/core 3.64.4 → 3.64.5-staging.293

package/.changeset/customer-sites-one-row-per-site.md

@@ -0,0 +1,19 @@
+---
+"@7365admin1/core": patch
+---
+
+Return one row per site from `/api/customer-sites`, named by the site.
+
+`getAll` grouped by `{ name, site }`. A customer-sites row is an ENGAGEMENT and
+one site can carry more than one, so two rows for the same site with different
+names both survived as "distinct" — a provider's site list showed four entries
+for three sites, and the site switcher ticked two at once.
+
+`name` is also a snapshot from when the engagement was created and goes stale
+when the site is renamed; recency is no guide, since the newer row held the
+staler name. The site is now looked up and its live name projected over the
+snapshot, with the stored name kept as a fallback.
+
+The search and the sort both run after the rename, so a site is found and
+ordered by the name it actually has, and the count is derived from the same
+pipeline.

package/.changeset/hid-duplicate-enrollment.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": minor
+---
+
+Refuse to enrol the same person on one HID reader twice.
+
+`POST /readers/:readerId/identities` and `PATCH /identities/:identityId` now
+check whether the linked resident, staff member or service provider already
+holds a HID user on that reader, and refuse with a 400 naming the user that is
+in the way. The existing duplicate check in `addIdentity` could not catch this:
+it asks about the reader's own keys, and enrolment allocates a fresh
+`hidUserId` and registration every time, so a second enrolment of one person
+looked entirely new while leaving the reader holding two users for one human.
+
+The check is reader-scoped on purpose — the same person enrolled at a different
+gate is normal. Visitors are excluded, because their identity is re-issued
+rather than duplicated and a returning visitor legitimately gets a new
+credential on the same reader.
+
+`GET /readers/:readerId/identities` takes an optional `person` filter so the
+enrolment form can ask the same question before it writes anything to the
+device.

package/.changeset/hid-facial-error-wording.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Say what a rejected face photo actually means.
+
+A facial failure was passed through as the reader wrote it, so an operator was
+shown `HID facial enrollment failed - code 3: Face exists Scores:
+{"bounds_width":240,...}`. The code is the device's, the scores are its quality
+figures for the photo, and neither says what went wrong or what to do.
+
+The codes we have seen the reader return are now written as sentences: a face
+already enrolled under another HID user, a face too close to the camera, a face
+not square to it, a face too near the photo's edge. The device's own codes are
+quoted once at the end so support still has them, and a code we have not seen is
+passed through verbatim rather than guessed at.
+
+The raw errors and quality scores move off the message and onto the
+`hid-amico-events` row, which is where a rejected photo gets diagnosed later.
+They were the least useful half of a modal and the most useful half of a log.

package/.changeset/hid-identity-user-link.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": minor
+---
+
+Store the user account on a HID identity, and recognise one person across every
+id they are filed under.
+
+An identity's link fields name a RECORD, and different screens name the same
+human through different records: permission reconciliation writes `user` and
+`member`, the enrolment screen writes `person`, and the enrolment picker itself
+has offered two different things over time, since `loadPermissionSubjects`
+returns a `site.people` id for a resident with an account and a `users` id for
+one without. The duplicate check compared field to matching field, so it saw
+none of it. One reader was found holding three HID users for one resident, keyed
+`user`, `person`-as-user-id and `person`-as-people-id.
+
+`createIdentity` and `updateIdentity` now resolve the subject's account through
+`resolvePermissionUserBindings`, the same resolver the permissions screen uses,
+and store it as `user` alongside the record link. The duplicate check matches
+every id that names the subject against every field that can hold one, so a
+resident already enrolled through any screen is refused rather than duplicated.
+
+`GET /readers/:readerId/identities` gains a `subject` filter that asks the same
+question, so the enrolment screen can warn before it writes anything to the
+device instead of failing at submit. The existing `person` filter is unchanged
+and remains an exact match on that one field.

package/.changeset/hid-objectid-across-driver-copies.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": patch
+---
+
+Stop the HID repository mistaking every id it reads from Mongo for "not an id".
+
+`optionalObjectId` in `hid-amico.repo.ts` identified ObjectIds with
+`instanceof`. That only ever holds for an id this file minted itself: three
+copies of the `mongodb` package are installed across `iservice365-core`,
+`iservice365-utils` and `iservice365-API-core`, and `useAtlas` opens its
+connection with the one under `iservice365-utils`, so every id on every
+document it returns belongs to a different class. `instanceof` was false and
+the value fell through to a `typeof value !== "string"` branch that returned
+null.
+
+The visible effect was enrolment. `assertPermissionSubject` treats a resident
+as valid only when their `site.people` record carries a linked user account,
+and it read that link through this helper — so a resident with an account read
+as a resident without one, and `POST /readers/:readerId/identities` answered
+400 "The linked HID identity subject is not active at this site." for residents
+who were perfectly enrollable.
+
+Ids are now read structurally, by `toHexString`, which every copy's ObjectId
+has. `toValidatedId` goes through the same helper, so it too stops rejecting
+ids that came from the database. `hid-amico.model.ts` already read ids this
+way; this brings the repository in line with it.

package/.changeset/hid-profile-qr-backend.md

@@ -0,0 +1,31 @@
+---
+"@7365admin1/core": minor
+---
+
+Let a signed-in member hold their own HID QR code.
+
+`GET`, `POST` and `DELETE /readers/:readerId/profile-qr` read, issue and revoke
+the caller's own QR credential on one reader. The caller comes from the session,
+so there is no user id in the path to point at somebody else, and each handler
+calls `authorizeReader` for itself rather than trusting the router - the site is
+re-resolved from the stored reader record.
+
+The credential is the visitor mechanism: an alphanumeric value in the reader's
+`qrcodes` table, with the reader put into the QR-readable configuration first.
+Unlike a visitor pass it carries no validity window, matching the member's
+facial enrollment, which is standing until removed. Issuing replaces any earlier
+code for that member on that reader, and the replacement is written and verified
+before the old one is removed.
+
+It creates no access rule, deliberately. `setProfileFacial` beside it does not
+either: a member's door access comes from the HID permissions screen, and
+minting a rule here would mean anyone who can press Generate admits themselves.
+The read reports whether that screen admits them, resolved through
+`resolvePermissionUserBindings` - the same resolver that writes the rules onto
+the device - so the answer is the one the reader will actually be asked.
+
+Two settings are now readable that were already writable: the QR identification
+and legacy-mode flags `configureVisitorQrReader` sets on every issue, plus
+`access_rule_time_zones` alongside its two sibling link tables. Whether a reader
+was set up to accept a QR, and whether an access rule had a schedule, were
+invisible to every screen and every diagnosis.

package/.changeset/hid-reader-user-search.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Make the search on the HID reader user roster work.
+
+`listReaderUsers` asked the device to filter. Amico's `where` takes a value or a
+list of values per column and has no operator form, so the substring clause it
+sent for a text term, `{name: {LIKE: "%x%"}}`, was answered
+`400 Invalid value (string or array expected)`. Every search by name threw, and
+the screen showed "Unable to load HID users from reader" with an empty table.
+
+A numeric term took a different branch that matched the HID user id exactly.
+That did not fail, it answered wrongly: searching a registration number like
+`000004` resolved to `id = 4` and returned a different person.
+
+Rows are already pulled in one page and filtered here for `userType`, so the
+search now joins that filter as a case-insensitive substring over name, id and
+registration - the same three fields, and the same "contains" semantics, the
+identities search uses. Verified against a live reader: a name matches
+partially and case-insensitively, a registration number returns its own user,
+a full UID still works, and no match returns an empty page rather than an error.

package/.changeset/member-lookup-follows-site.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": patch
+---
+
+A person's role now follows the site they are on.
+
+`GET /api/members/user/:id/app/:type` accepts an optional `?site=` (a 24-hex
+site id, like `?org=`). When it is sent, the answer is the person's live
+membership of that app type pinned to that site (inside `?org=` when it is also
+sent); failing that, their organisation-wide membership in `?org=`; failing
+that, any live membership in `?org=`. When none of these exists the route
+answers exactly as before. A removed membership never wins, and a site never
+turns a found membership into "not found". Callers that do not send `site`
+see no change. Login, auth-v2 and verification are unchanged.
+
+The rule is the pure `pickSiteMembership` in `utils/member-lookup.util.ts`.

package/.changeset/module-gate-foundation.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Lay the groundwork for module lists becoming a gate, without narrowing anyone.
+
+- New `utils/module-gate.util.ts`: the list of modules a client's list can
+  govern (generated from layer-common 5a96f95), the spelling groups, the
+  always-included set, and pure functions that work out which modules a
+  caller's apps must hide (`deniedModules`) and who would lose what if a list
+  changed (`moduleImpact`). Nothing calls them yet.
+- The organisation and site module checks now treat every spelling of a module
+  as the same module (ticking `workOrder` also allows `work_orders`,
+  `work_order` and `work-orders`), and never refuse members, invitations, roles,
+  sites, customers, subscriptions, payment methods or site settings. This only
+  ever refuses less than before.
+- A Site Settings save (`PATCH /api/sites/id/:id`) now always keeps the site's
+  stored module list. Before this, the save replaced `metadata` wholesale and
+  could wipe or overwrite that list. `PATCH /api/sites/:id/modules` is the only
+  way to change it.

package/.changeset/org-update-diagnosable-error.md

@@ -0,0 +1,14 @@
+---
+"@7365admin1/core": patch
+---
+
+Say what is wrong when an organisation cannot be saved.
+
+`PUT /api/organizations/:id` — the write behind onboarding step 1 and the staff
+Client List edit — collapsed every MongoDB write error into a 500 reading
+"Failed to update organization.", with only `error.message` in the log. A
+duplicate-key refusal (the `organizations` collection still carries a unique
+index an earlier version of this file created and nothing ever dropped) is now
+a 400 naming the field the caller has to change, a typed error raised
+underneath is no longer turned into a 500, and the log line carries the error
+name, code, key and the organisation id.

package/.changeset/patrol-email-scope-restore.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": patch
+---
+
+Restore and extend the site scoping on the patrol-log email endpoints.
+
+#1967 added a `requireSiteReach` guard to `POST /api/patrol-logs/email`. #1981,
+branched before #1967 landed, rewrote the same controller to add the history
+endpoints and dropped the guard. Neither repo runs its tests in CI, so the e2e
+test #1967 shipped has been failing on `main` unnoticed ever since.
+
+All five endpoints now resolve the caller from the session: the two that name a
+site (`send`, `getAll`) check that site, and the three that name a record
+(`resend`, `getById`, `deleteById`) check the site stored on the record. The
+`createdBy` pinning is restored with them, so a send cannot be filed under
+another user's name.

package/.changeset/people-occupied-structure.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Add `getOccupiedStructure` to the people module: the blocks, levels and units at one site that actually have a person of a given type (`resident` and `tenant` by default), so a block/level/unit picker can offer only locations where the person step has an answer. Site-scoped and authorised with `requireSiteReach` before any person record is read; the status and type filter is `getPeopleByUnit`'s exactly, so a unit is never offered whose person list then comes back empty.

package/.changeset/resident-app-module-ceiling.md

@@ -0,0 +1,18 @@
+---
+"@7365admin1/core": minor
+---
+
+Add the organisation tier over the resident-app modules (R4).
+
+`organizations.residentAppModules` is the ceiling over the per-site
+`sites.metadata.residentAppModules` that property-management's Site Settings
+panel already writes. `GET /api/sites/:id` now also returns
+`metadata.residentAppModulesEffective`, the two tiers intersected, because the
+resident app cannot read its own organisation and so cannot apply the ceiling
+itself. The saved per-site field is returned unchanged alongside it, so the
+settings panel still reads back what it wrote.
+
+Only an explicit `false` disables, at either tier, so absent keeps meaning
+everything and this is inert for every organisation until Seven365 sets a
+ceiling. A site write that switches ON a module the client was not given is
+refused by name.

package/.changeset/role-module-ceiling.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": minor
+---
+
+Enforce the organisation's module ceiling on every role write (R1 tier three).
+
+A role can no longer be granted a permission whose module Seven365 never gave
+the organisation, nor one the organisation never gave the site. Applied to all
+four write paths — `role.controller` create / update / updatePermissionsById and
+`role-v2.controller` create — because `/api/roles/v2` is a separate mount and
+gating one leaves the rule reachable by adding `/v2` to the URL.
+
+Only what a write ADDS is tested, so a role that predates the module list can
+still be renamed and can still have a permission removed. Absent and empty
+module lists still mean everything at every tier, so this is inert for all 168
+live organisations until Seven365 sets a list.

package/.changeset/role-read-self-arm.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope `GET /api/roles/id/:id`: a caller may read a role they themselves hold (resolved from the session's own `members` rows), otherwise the role's organisation rule applies. Closes the cross-tenant read of any organisation's role name and permissions.

package/.changeset/role-v2-platform-grant.md

@@ -0,0 +1,14 @@
+---
+"@7365admin1/core": patch
+---
+
+Stop `/api/roles/v2` minting a role that holds the console's own resources.
+
+`role.controller createRole` has carried `requireNoPlatformGrant` for a while;
+`role-v2.controller createRole` did not. It is a separate controller behind a
+separate route and accepts any permission string, so the hole was reachable by
+adding `/v2` to the URL.
+
+Measured on production before adding: no site-scoped role holds a platform-only
+string, and this mount requires a `site`, so the check refuses nothing that
+exists today. It only ever refuses a NEW grant regardless.

package/.changeset/site-module-allowlist.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Tier two of the module cascade: `sites.metadata.modules`, the modules a site offers, plus `PATCH /sites/:id/modules` for the organisation to set it. The write refuses any key Seven365 never gave the organisation (owner requirement R1); the read fails open at every tier, so absent and empty both mean "everything the organisation has" and no site or role editor changes until somebody sets a list.

package/.changeset/site-save-resident-ceiling.md

@@ -0,0 +1,7 @@
+---
+"@7365admin1/core": patch
+---
+
+Site Settings saves are no longer refused because the client has one resident-app
+switch turned off. A save is refused only when it would turn ON a resident-app
+switch that the site has stored as off and the client has switched off.

package/.changeset/user-email-allowlist-subscription-authz.md

@@ -0,0 +1,21 @@
+---
+"@7365admin1/core": patch
+---
+
+Narrow the account-by-e-mail lookup to identity only, and scope the two open subscription reads
+
+`GET /api/users/email/:email` and its v2 twin `GET /api/users/v2/email/:email`
+stripped the password hash and session id from the reply but answered every
+other stored field, so any signed-in account could read any other account's
+NRIC, contact number, date of birth, gender, default organisation, status and
+profile just by knowing the e-mail address — across every client on the
+platform. Both now answer `{_id, name, email}` and nothing else. An
+organisation gate would have been the wrong fix: this endpoint exists for the
+invite flow, where the person being looked up is deliberately not in the
+caller's organisation yet.
+
+`GET /api/subscriptions/org/:id` answered any organisation's billing record —
+plan, seat count, price, currency, renewal date — to any signed-in account, and
+`GET /api/subscriptions/` answered every subscription on the platform in one
+list. They now carry `requireOrgAccess` and `requirePlatformStaff`, the two
+gates already used elsewhere in the same file.