@7365admin1/core 3.48.1-staging.148 → 3.48.1-staging.150

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

@@ -0,0 +1,60 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the three remaining `/api/members` writes to the membership they name.
+
+`PUT /api/members/id/:id/role/:role/type/:type/org/:org`,
+`PUT /api/members/site` and `PUT /api/members/:id/onboarding/complete` all
+carried `requireAuth` and nothing more, and each took the membership id straight
+out of the request.
+
+**The role write is the sharp one.** A role IS the permission set, so
+re-pointing a membership at another role is an access grant. The service already
+refused to hand a *Seven365 staff* role to a non-staff caller, but a **tenant**
+role was still free: quoting another client's membership id re-pointed it at any
+of that client's roles, their **owner** role included — and equally could demote
+that client's own admin. The `org` in the URL was also what the service used to
+look up owner roles for its "last owner" precondition, so a mismatched one ran
+that safety check against the wrong client's roles entirely.
+
+`PUT /api/members/site` took the membership id **and** the target site from the
+body, so nothing said whose membership, or whose site, either one was — any
+signed-in account could move any client's member onto any estate.
+
+`PUT /api/members/:id/onboarding/complete` took the id from the URL and nothing
+else, so any signed-in account could mark any client's membership onboarded and
+skip that client's onboarding gate.
+
+All three now decide from the **stored** membership, through the
+`requireMemberOrg` helper this controller already uses for
+`PUT /api/members/:id/:status`:
+
+- the organisation recorded on the membership is authorised with
+  `requireOrgAccess` — Seven365 staff, or a live member of that organisation.
+- a membership with **no** organisation is a platform staff row; only Seven365
+  staff may touch it. A missing org is refused, not waved through.
+- the role write additionally refuses when the `org` in the URL disagrees with
+  the one on the membership, so the service's owner-role lookup can no longer be
+  pointed at another client.
+- `PUT /api/members/site` puts the incoming site through `requireSiteReach`, the
+  same rule `/api/vehicles` and `/api/documents` use, so a member cannot be moved
+  onto an estate the caller cannot reach. An unreachable site answers as one that
+  does not exist (404), so site ids cannot be enumerated from the difference.
+
+Guards sit **after** each handler's Joi validation, so a malformed id still
+answers 400 exactly as it does today.
+
+Scope note — deliberately NOT changed here: the four read-by-user routes
+(`GET /api/members/user/:id`, `/users/:id`, `/user/:id/app/:type`,
+`/user/:id/app/:type/org`). `layer-common ServiceProviderMain.vue:922,1320` and
+`InvitationClientForm.vue:324` legitimately read the memberships of a user who
+belongs to a **service provider's** organisation, not to the caller's, and no
+existing helper expresses "an organisation my organisation has engaged". That
+needs a product decision rather than a guess. Every other caller passes its own
+user id. `POST /api/members/direct` and `POST /api/members/verification/:id` are
+also unchanged — the latter is driven entirely by a single-use, expiring
+invitation record and grants the caller nothing.
+
+Nothing changes for a permitted caller: same response shape, same fields, same
+status.

package/dist/index.d.ts

@@ -4890,6 +4890,12 @@ type TPatrolLog = {
     cameras: Array<logCamera>;
     status: Array<string>;
     incidentReport: incidentReport;
+    /**
+     * The user who created the log. Stored as a reference only — the name is
+     * resolved from `users` at read time, so a renamed account shows its current
+     * name rather than whatever it was called when the log was filed.
+     */
+    createdBy?: string | ObjectId | null;
     platform?: string;
     createdAt?: Date | string;
     updatedAt?: Date | string;
@@ -4910,6 +4916,7 @@ declare function MPatrolLog(value: TPatrolLog): {
     status: string[];
     route: string | ObjectId | undefined;
     incidentReport: incidentReport;
+    createdBy: string | ObjectId | null;
     platForm: string;
     createdAt: string | Date;
     updatedAt: string | Date;
@@ -9847,7 +9854,7 @@ declare function MHidAmicoIdentity(value: THidAmicoIdentity): {
     member: ObjectId | undefined;
     serviceProvider: ObjectId | undefined;
     visitor: ObjectId | undefined;
-    type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+    type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
     status: "deleted" | "active" | "inactive";
     metadata: Record<string, unknown>;
     createdAt: string | Date;
@@ -9951,7 +9958,7 @@ declare function useHidAmicoRepo(): {
         member: ObjectId | undefined;
         serviceProvider: ObjectId | undefined;
         visitor: ObjectId | undefined;
-        type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+        type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
         status: "deleted" | "active" | "inactive";
         metadata: Record<string, unknown>;
         createdAt: string | Date;
@@ -10308,7 +10315,7 @@ declare function useHidAmicoService(): {
         member: bson.ObjectId | undefined;
         serviceProvider: bson.ObjectId | undefined;
         visitor: bson.ObjectId | undefined;
-        type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+        type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
         status: "deleted" | "active" | "inactive";
         metadata: Record<string, unknown>;
         createdAt: string | Date;