@7365admin1/core 3.64.5-staging.308 → 3.64.5-staging.310

package/CHANGELOG.md

@@ -1,5 +1,220 @@
 # @iservice365/core
 
+## 3.68.3
+
+### Patch Changes
+
+- 1d5050b: Re-inviting the same person to the same app, organisation and site now re-sends the pending invitation instead of adding a duplicate; invite request logs no longer record the invitee's e-mail address.
+
+## 3.68.2
+
+### Patch Changes
+
+- d9e0ded: A duplicate membership insert now returns 400 "The user is already a member of this organization." instead of a 500.
+
+## 3.68.1
+
+### Patch Changes
+
+- 689b152: POST /api/people: count cross-client person creation (gate ships switched off)
+
+  The signed-in branch of `POST /api/people` checked only that somebody was signed
+  in. The site and organisation came straight from the request body, and where that
+  body carries an e-mail, a password and a resident/tenant type, the service goes on
+  to create a **user account** and an **active membership** as well as the person row.
+
+  `site.people` is the collection every site-reach decision on the platform reads its
+  verdict from, so a row written there is not an ordinary record — it manufactures
+  reach into another client's estate.
+
+  This adds the site-reach check the camera, HID and people-list paths already use,
+  behind `PEOPLE_CREATE_REACH_MODE`, and **ships it in `log` mode**: it records what
+  it would refuse and refuses nothing. `enforce` refuses; `off` does not look. Any
+  unexpected error allows the request — this must never be why a real registration
+  fails.
+
+  It ships off because of RP-5. A person row carries no `createdBy`, so who created
+  the existing rows cannot be established retrospectively and the true refusal count
+  is only knowable from live traffic. Measured read-only on staging: 372
+  `site.people` rows, of which exactly **1** is self-signup shaped (`platform:
+"mobile"`, `status: "pending"`) and 371 were written by a signed-in caller, across
+  3 of 256 sites.
+
+  Pre-login self-signup is untouched in every mode: a request with no session takes
+  the other branch of `add` before this runs, and that route is already constrained
+  by its own allow-list schema with `status` and `platform` pinned server-side.
+
+## 3.68.0
+
+### Minor Changes
+
+- d7e9298: Manpower live status: an authenticated namespace beside the open one
+
+  `/manpower` streams every client site's live staffing level — how many guards are
+  actually on shift against how many were promised — to anyone who connects, with no
+  credential of any kind.
+
+  This adds `/manpower-live`, carrying exactly the same `manpower-status-update`
+  events, which admits a socket only when the handshake presents a session id that
+  resolves to a live session. Every refusal is an identical `Unauthorized`, and a
+  session store that is down refuses rather than letting everyone in.
+
+  `/manpower` itself is deliberately unchanged: the Capacitor guard app installed on
+  phones today and the Nuxt security screen both connect to it with no credential and
+  would be cut off the moment it were tightened. Every update is emitted to both, so
+  the two feeds can never disagree, and both namespaces share one connection handler,
+  so a client on the authenticated feed still starts the poll and still gets an
+  immediate snapshot.
+
+  A live session is the whole check, deliberately. Scoping the feed to the caller's
+  own sites is not possible today: manpower lives in HRM Labs' vendor id space, none
+  of those site ids match ours, and no field links the two — a site check would empty
+  the screen for the one customer using it. That mapping is a schema change and
+  belongs to the leads.
+
+### Patch Changes
+
+- 87c8679: Module gate: the kill switch now stops the 409, and the check stops reading when there is nothing to decide
+
+  Two follow-ups from the module-gate server review, both behaviour-neutral for
+  anybody who is not using the kill switch.
+
+  **`MODULE_LIST_GATE=off` now means off.** Every other part of the gate checked the
+  master switch; `mustAcknowledge` did not. So with the gate switched off, a save that
+  narrowed a client's module list was still refused with a 409 "acknowledge the impact
+  first" — the one lever a lead would reach for in an emergency, not working for the
+  one path that blocks a save from going through. Both the organisation and the site
+  save paths go through that function, so both are fixed. With the switch at its
+  default the 409 behaves exactly as before, and that is asserted.
+
+  **`moduleDeniedForCaller` no longer reads memberships when no list is enforced.** It
+  runs on every governed request and read the caller's memberships before finding out
+  whether there was anything to decide — and `members.user` has no index to use. It now
+  returns early unless the site or its organisation has an enforced list, which is what
+  the notification filter already did. No verdict changes: a client that really has an
+  enforced list is still measured exactly as before, and that is asserted too.
+
+  Also corrects the 3.65.0 changelog, which claimed `MODULE_LIST_GATE` switched all of
+  the gate off at once. It did not, for the reason above.
+
+## 3.67.0
+
+### Minor Changes
+
+- 7b9ea2f: Notifications: stop sending alerts for modules a client was never given
+
+  `NOTIFY_ACCESS_FILTER` now defaults to `on` instead of `log`, so the module-based
+  drop is real: a recipient no longer gets a notification when every membership they
+  hold at the site denies every module the notification's category is about.
+
+  Only the module drop acts. The role-based check is still computed and logged and
+  never drops anybody, because most apps do not enforce their role gates yet and a
+  role-based drop would hide alerts for screens people can still open.
+
+  Unchanged: residents, anyone with no membership at the site, Seven365 staff, sends
+  with no site, and categories the catalogue does not govern are all exempt; any
+  error sends to everyone; and `MODULE_LIST_GATE=off` still disables it entirely.
+  `NOTIFY_ACCESS_FILTER=log` or `off` overrides this default with no deploy.
+
+  This is inert until a client's module list is enforced — measured read-only on
+  staging at the time of the flip, no organisation (0 of 199) and no site (0 of 256)
+  had a stored list and there were no acknowledged-save markers, so nothing is
+  dropped for anybody until a Super Admin saves a module list with the acknowledged
+  preview.
+
+## 3.66.0
+
+### Minor Changes
+
+- b7f6302: Add a staff-only handler that repairs an organisation's missing owner membership.
+
+  An organisation created before 3.60.0 can exist with no `members` row at all, so
+  `GET /api/members/user/:id/app/organization` answers 404 and every console
+  landing page tells the real owner that no organisation exists. The new
+  `orgOwnerRepairHandlers` writes the one membership the onboarding path already
+  writes, for one organisation at a time, and only when that organisation is
+  active, holds exactly zero `organization` memberships, and has an account
+  registered under its own e-mail address. Staff-only (`organizations` console
+  permission), idempotent under a one-writer claim, audited, and behind the
+  `ORG_OWNER_REPAIR` switch. No schema change and no migration.
+
+## 3.65.2
+
+### Patch Changes
+
+- fcd2f1e: `GET /api/members/users/:id` no longer shows anybody's memberships to any signed-in account. The person and Seven365 staff still get the full list; anyone else gets only the memberships in organisations they belong to, were invited to or own (an empty list, not an error, when there are none).
+
+## 3.65.1
+
+### Patch Changes
+
+- 69714b4: Role writes: a site's own module list narrows a role only when the site belongs to the role's organisation. A service provider's role at a client's site is no longer refused modules the client switched off for that site — matching what the role editor now offers.
+
+## 3.65.0
+
+### Minor Changes
+
+- c4dc50b: Module gate, server step: the deny-list endpoint, the impact preview, and
+  acknowledge-before-save. Everything ships inert and fails open.
+
+  - `useMemberController().getModulesByUserIdType` (for
+    `GET /api/members/user/:id/app/:type/modules?org=&site=`) answers
+    `{ denied: string[] }` for the membership `getByUserIdType` answers with. It
+    is the same self-or-staff guard. It answers `[]` for no list, an empty list,
+    a resident, Seven365 staff, a site of another organisation, any lookup
+    error, and `MODULE_LIST_GATE=off`. `ALWAYS_ALLOWED` is never denied.
+  - A saved list is enforced only once it has been saved through the
+    acknowledged preview. The marker is the save's own append-only console-audit
+    row (`gateListHash`). A list saved earlier, or changed any other way, behaves
+    as absent. No field is added to any organisation or site.
+  - `useOrgController().previewOrgModules` and
+    `useSiteController().previewSiteModules` (for
+    `POST /api/organizations/:id/modules/preview` and
+    `POST /api/sites/:id/modules/preview`) return who would lose what. They are
+    read-only and never go through `GET /api/roles`.
+  - `updateModules` and `updateSiteModules` accept `acknowledgeImpact`. A save
+    that takes a module away from somebody is refused with 409 until it is
+    acknowledged. An empty list restores everything and never needs it. Site
+    saves are now recorded in the console audit (`site.modules-changed`).
+  - `filterByAccess` (Q7) runs at the top of the notification `send()`. It is
+    `NOTIFY_ACCESS_FILTER=log` by default: it logs who would be filtered and
+    still sends to everyone. It is exported so API-core's own sender can call it.
+  - `moduleDeniedForCaller` (Q3) is the server-refusal primitive. It is
+    `MODULE_GATE_MODE=log` by default and never refuses. `enforce` refuses only
+    the keys in `MODULE_GATE_ENFORCE_KEYS`. Work stamped (`at`) before the
+    acknowledged save is accepted.
+  - `MODULE_LIST_GATE` (code default `on`) switches all of the above off at
+    once. CORRECTION (3.68.0): it did not. `mustAcknowledge` never read it, so
+    with the gate off a narrowing save was still refused with a 409. Fixed in
+    3.68.0; every other path did check it.
+
+### Patch Changes
+
+- c993ee4: POST /api/members/direct refuses (400) a role that belongs to a different organisation, unless the caller already holds that role in the organisation being joined.
+- 74f228f: POST /api/members/direct: adding yourself now needs a role you may give yourself - Seven365 staff, the organisation's owner, a role you already hold there, or the role your own invitation offers. Enrolling somebody else is unchanged.
+- ae42c1c: GET /api/organizations/id/:id returns the whole organisation record only to a caller with a relationship to it (member, invitee, owner, Seven365 staff, an active resident of one of its sites, or an engaged service provider). Everyone else gets the name-only record the anonymous lookup already returns. It never answers 401/403.
+- 7363b8d: 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.
+- 9d1a0f0: PATCH /api/users/field/:id (and v2): on your own account you may change only name, contact, nric, dateOfBirth, profile and gender, and defaultOrg to an organisation you reach. status, email and plateNumber are staff-only.
+
+## 3.64.5
+
+### Patch Changes
+
+- 49e1aef: 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`.
+
 ## 3.64.4
 
 ### Patch Changes

package/package.json

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

package/.changeset/member-duplicate-400.md

@@ -1,5 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-A duplicate membership insert now returns 400 "The user is already a member of this organization." instead of a 500.