@7365admin1/core 3.47.1-staging.134 → 3.47.1-staging.136

package/.changeset/member-read-and-status-scope.md

@@ -0,0 +1,40 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the member list and the member suspend/reactivate write to their own organisation.
+
+`GET /api/members` took its `org` and `siteId` straight out of the query string,
+and `PUT /api/members/:id/:status` took the member id straight out of the URL.
+Both carried `requireAuth` and nothing more. So any signed-in account on the
+platform could list another client's staff, and suspend or reactivate any member
+of any client.
+
+`GET /api/members` also had a hole in its own scope requirement. Line 170 refused
+a query that named neither an organisation nor a user — **unless**
+`type === "admin"`, which then listed Seven365's own staff to anybody signed in.
+
+Both now decide from the session:
+
+- `type=admin` requires Seven365 staff. That query belongs to the staff console
+  (`web-app-org pages/super-admin`), so it is gated rather than removed.
+- a caller-supplied `org` is checked with `requireOrgAccess` before it is used —
+  Seven365 staff, or a live member of that organisation.
+- `user` on its own stays open for the caller's OWN id, because "which
+  organisations am I a member of" is every service app's landing page
+  (`web-app-security pages/index.vue:118` and its siblings). Asking it about
+  somebody else now requires staff.
+- `PUT /api/members/:id/:status` loads the stored membership and authorises on
+  the organisation recorded on it — never one from the request. A membership with
+  no organisation is a platform staff row, and only Seven365 staff may touch it;
+  a missing org is refused, not waved through.
+
+Service providers are not special-cased and do not need to be: a provider holds a
+membership in the organisation whose site it works on — that is how
+`GET /api/members/user/:id/app/:type?org=` finds its own row at sign-in — so the
+guard app's member list (`isecure365-mobile-app
+src/features/patrol/use-patrol.ts:180`, which sends `org: site.org` with a
+`siteId`) passes on the ordinary rule.
+
+Nothing changes for a permitted caller: same response shape, same fields, same
+status.

package/.changeset/vehicle-approve-permission-prefix.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Check the vehicle-approval permission under the resource name the catalogues
+actually grant.
+
+When a security agency adds a vehicle, the vehicle is parked at `PENDING` unless
+the caller may approve one. `vehicle.service.ts:125` asked for
+`vehicleManagement:approve-vehicle`, but every catalogue that can grant a
+permission spells that resource `vehicle-mgmt` — `web-app-security`
+`composables/useSecurityPermission.ts:87,111`, `web-app-org`
+`composables/usePropertyPermission.ts:312`, `ma-mobile-app`
+`src/features/permissions/permission.catalog.ts:7`, `isecure365-mobile-app`
+`src/features/permissions/permission.catalog.ts:32`. Only the prefix differed,
+so the string checked here was one no role could hold and the bypass could never
+be reached by granting the permission — the agency's vehicles stayed pending
+however the role was set up. `vehicleManagement:` appears nowhere else in any
+repository in the organisation.
+
+The `*` wildcard branch is untouched, so a role holding all permissions behaves
+exactly as before; this only makes the specific grant work as intended.

package/dist/index.js

@@ -19042,6 +19042,14 @@ function useMemberService() {
 }
 
 // src/controllers/member.controller.ts
+async function requireMemberOrg(req, org) {
+  const orgId = org?.toString() ?? "";
+  if (!orgId) {
+    await requirePlatformStaff(req);
+    return;
+  }
+  await requireOrgAccess(req, orgId);
+}
 function useMemberController() {
   const {
     getByUserId: _getByUserId,
@@ -19049,6 +19057,7 @@ function useMemberController() {
     getOrgsByMembership: _getOrgsByMembership,
     getByUserIdType: _getByUserIdType,
     getByUserIdTypeOrg: _getByUserIdTypeOrg,
+    getById: _getMemberById,
     updateMemberStatus: _updateMemberStatus,
     updateStatusByUserId: _updateStatusByUserId,
     updateSiteById: _updateSiteById
@@ -19176,6 +19185,13 @@ function useMemberController() {
       return;
     }
     try {
+      if (type === "admin") {
+        await requirePlatformStaff(req);
+      } else if (org) {
+        await requireOrgAccess(req, org);
+      } else if (user && user !== callerId(req)) {
+        await requirePlatformStaff(req);
+      }
       const items = await _getAll({
         search,
         page,
@@ -19242,6 +19258,8 @@ function useMemberController() {
     const _id = req.params.id;
     const status = req.params.status;
     try {
+      const existing = await _getMemberById(_id);
+      await requireMemberOrg(req, existing?.org);
       await _updateMemberStatus(_id, { status });
       res.json({ message: "Successfully updated member status." });
       return;
@@ -32169,7 +32187,7 @@ function useVehicleService() {
       user,
       org: value.org
     });
-    const hasSecurityBypass = addedBySecurity && Array.isArray(userPermissions) && (userPermissions.includes("*") || userPermissions.includes("vehicleManagement:approve-vehicle"));
+    const hasSecurityBypass = addedBySecurity && Array.isArray(userPermissions) && (userPermissions.includes("*") || userPermissions.includes("vehicle-mgmt:approve-vehicle"));
     if (hasSecurityBypass) {
       addedByPM = true;
     }