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

package/.changeset/user-invite-dedupe.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+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.

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/dist/index.d.ts

@@ -1057,6 +1057,10 @@ declare class MVerification implements TVerification {
     constructor(value: TVerification);
 }
 
+type TKeyValuePair<K extends string | number | symbol = string, V = any> = {
+    [key in K]: V;
+};
+
 declare function useVerificationRepo(): {
     createIndex: () => Promise<void>;
     createTextIndex: () => Promise<void>;
@@ -1076,6 +1080,10 @@ declare function useVerificationRepo(): {
     }) => Promise<{}>;
     getByIdByType: (type: string) => Promise<TVerification[]>;
     updateStatusById: (_id: string | ObjectId, status: string, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
+    reissuePendingById: (_id: string | ObjectId, { metadata, expireAt }: {
+        metadata: TKeyValuePair;
+        expireAt: string;
+    }) => Promise<number>;
     getByStatus: (status: string) => Promise<TVerification[]>;
     findOne: (query: any) => Promise<mongodb.WithId<bson.Document> | null>;
     completePendingInvites: ({ email, orgId, siteId, app, session, }: {
@@ -1087,10 +1095,6 @@ declare function useVerificationRepo(): {
     }) => Promise<mongodb.UpdateResult<bson.Document>>;
 };
 
-type TKeyValuePair<K extends string | number | symbol = string, V = any> = {
-    [key in K]: V;
-};
-
 declare function useVerificationService(): {
     createUserInvite: ({ email, metadata, }: {
         email: string;

package/dist/index.js

@@ -11278,9 +11278,6 @@ var import_node_server_utils45 = require("@7365admin1/node-server-utils");
 // src/services/verification.service.ts
 var import_node_server_utils41 = require("@7365admin1/node-server-utils");
 
-// src/repositories/verification.repo.ts
-var import_node_server_utils19 = require("@7365admin1/node-server-utils");
-
 // src/models/verification.model.ts
 var import_node_server_utils18 = require("@7365admin1/node-server-utils");
 var import_mongodb16 = require("mongodb");
@@ -11329,6 +11326,7 @@ var MVerification = class {
 };
 
 // src/repositories/verification.repo.ts
+var import_node_server_utils19 = require("@7365admin1/node-server-utils");
 var import_mongodb17 = require("mongodb");
 function useVerificationRepo() {
   const db2 = import_node_server_utils19.useAtlas.getDb();
@@ -11558,6 +11556,28 @@ function useVerificationRepo() {
       throw new import_node_server_utils19.InternalServerError("Error updating verification status.");
     }
   }
+  async function reissuePendingById(_id, { metadata, expireAt }) {
+    try {
+      _id = new import_mongodb17.ObjectId(_id);
+    } catch (error) {
+      throw new import_node_server_utils19.BadRequestError("Invalid verification ID format.");
+    }
+    try {
+      const result = await collection.updateOne(
+        { _id, status: "pending" },
+        { $set: { metadata, expireAt, updatedAt: (/* @__PURE__ */ new Date()).toISOString() } }
+      );
+      delNamespace().catch(
+        (err) => import_node_server_utils19.logger.error(`Failed to clear cache for namespace: ${namespace_collection3}`, err)
+      );
+      delCache((0, import_node_server_utils19.makeCacheKey)(namespace_collection3, { _id })).catch(
+        (err) => import_node_server_utils19.logger.error(`Failed to delete cache for verification ${_id}`, err)
+      );
+      return result.modifiedCount;
+    } catch (error) {
+      throw new import_node_server_utils19.InternalServerError("Error re-sending the invitation.");
+    }
+  }
   async function getByStatus(status) {
     try {
       const data = await collection.find({ status }).toArray();
@@ -11627,6 +11647,7 @@ function useVerificationRepo() {
     getVerifications,
     getByIdByType,
     updateStatusById,
+    reissuePendingById,
     getByStatus,
     findOne,
     completePendingInvites
@@ -17616,7 +17637,8 @@ function useVerificationService() {
     add,
     getById: _getById,
     updateStatusById: _updateStatusById,
-    getByStatus: _getByStatus
+    getByStatus: _getByStatus,
+    reissuePendingById
   } = useVerificationRepo();
   const { getUserByEmail } = useUserRepo();
   const { getById: getOrgById, getByEmail: getOrgByEmail } = useOrgRepo();
@@ -17691,13 +17713,6 @@ function useVerificationService() {
     }
     const verificationIds = [];
     for (const app of apps) {
-      await useVerificationRepo().findOne({
-        type,
-        email,
-        "metadata.app": app,
-        "metadata.org": metadata.org,
-        "metadata.siteId": metadata.siteId
-      });
       const value = {
         type,
         email,
@@ -17708,7 +17723,24 @@ function useVerificationService() {
         expireAt: new Date(Date.now() + 72 * 60 * 60 * 1e3).toISOString(),
         createdAt: (/* @__PURE__ */ new Date()).toISOString()
       };
-      const createdId = await add(value);
+      const stored = new MVerification({
+        ...value,
+        metadata: { ...value.metadata }
+      }).metadata;
+      const pending = await useVerificationRepo().findOne({
+        type,
+        // same address in any letter case, as `completePendingInvites` reads it
+        email: new RegExp(`^${email.replace(/[.*+?^$()|[\]{}\\]/g, "\\$&")}$`, "i"),
+        status: "pending",
+        "metadata.app": app,
+        "metadata.org": stored.org,
+        "metadata.siteId": stored.siteId
+      });
+      const reissued = pending?._id && await reissuePendingById(pending._id, {
+        metadata: stored,
+        expireAt: value.expireAt
+      });
+      const createdId = reissued ? pending._id : await add(value);
       verificationIds.push(createdId.toString());
       const link = `${APP_MAIN}/verify/invitation/${createdId}`;
       const emailContent = (0, import_node_server_utils41.compileHandlebar)({
@@ -29973,6 +30005,7 @@ function useMemberController() {
 // src/controllers/verification.controller.ts
 var import_node_server_utils66 = require("@7365admin1/node-server-utils");
 var import_joi28 = __toESM(require("joi"));
+var withoutEmail = (payload) => JSON.stringify({ ...payload, email: payload?.email ? "[redacted]" : void 0 });
 function callerId2(req) {
   const user = req.user;
   return user?.user?.toString?.() || user?._id?.toString?.();
@@ -30039,7 +30072,7 @@ function useVerificationController() {
     const payload = { ...req.body };
     import_node_server_utils66.logger.log({
       level: "info",
-      message: `[invite/user] payload: ${JSON.stringify(payload)}`
+      message: `[invite/user] payload: ${withoutEmail(payload)}`
     });
     const validation = import_joi28.default.object({
       email: import_joi28.default.string().email().required(),
@@ -30095,7 +30128,7 @@ function useVerificationController() {
     } catch (error2) {
       import_node_server_utils66.logger.log({
         level: "error",
-        message: `[invite/user] error for payload ${JSON.stringify(payload)}: ${error2.message}`
+        message: `[invite/user] error for payload ${withoutEmail(payload)}: ${error2.message}`
       });
       next(error2);
       return;
@@ -30105,7 +30138,7 @@ function useVerificationController() {
     const payload = { ...req.body };
     import_node_server_utils66.logger.log({
       level: "info",
-      message: `[invite/member] payload: ${JSON.stringify(payload)}`
+      message: `[invite/member] payload: ${withoutEmail(payload)}`
     });
     const validation = import_joi28.default.object({
       email: import_joi28.default.string().email().required(),
@@ -30157,7 +30190,7 @@ function useVerificationController() {
     } catch (error2) {
       import_node_server_utils66.logger.log({
         level: "error",
-        message: `[invite/member] error for payload ${JSON.stringify(payload)}: ${error2.message}`
+        message: `[invite/member] error for payload ${withoutEmail(payload)}: ${error2.message}`
       });
       next(error2);
       return;
@@ -30167,7 +30200,7 @@ function useVerificationController() {
     const payload = req.body;
     import_node_server_utils66.logger.log({
       level: "info",
-      message: `[service-providers/invite] payload: ${JSON.stringify(payload)}`
+      message: `[service-providers/invite] payload: ${withoutEmail(payload)}`
     });
     const validation = import_joi28.default.object({
       email: import_joi28.default.string().email().required(),
@@ -30224,7 +30257,7 @@ function useVerificationController() {
     } catch (error2) {
       import_node_server_utils66.logger.log({
         level: "error",
-        message: `[service-providers/invite] error for payload ${JSON.stringify(payload)}: ${error2.message}`
+        message: `[service-providers/invite] error for payload ${withoutEmail(payload)}: ${error2.message}`
       });
       next(error2);
       return;