@7365admin1/core 3.47.1-staging.137 → 3.47.1-staging.139

package/.changeset/customer-site-org-scope.md

@@ -0,0 +1,48 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `/api/customer-sites` to the organisations on the record.
+
+Every route on this module except the pre-login invite acceptance carried
+`requireAuth` and nothing more, and took the organisation straight out of the
+query string or the body (`customer-site.controller.ts`). Two things followed
+from that, and both are closed here.
+
+`POST /api/customer-sites` is not merely an engagement record: it CREATES A SITE
+inside whatever `siteOrg` the body names, and writes that site onto the
+organisation as its default when it has none
+(`customer-site.service.ts:77-111`). Any signed-in account on the platform — a
+resident, a cleaner, a guard — could therefore plant a site inside any client.
+
+A `customer.sites` row is also the cross-organisation access grant itself: the
+"engaged agency" branch of `resolveSiteAccess` reads it to decide who may reach
+a site's cameras, HID readers and residents
+(`camera-view.service.ts:325-341`). Being able to write, edit or delete those
+rows by id was being able to grant yourself reach into another client's estate,
+or revoke a contractor's.
+
+The caller is now resolved from the session and the decision made before
+anything is read or written:
+
+- `POST /` requires `requireOrgAccess` on the body's `org`, and on `siteOrg`
+  too when it names a different organisation — because that is where the new
+  site lands. The Add / Edit Site form sends the same id for both
+  (`web-app-org components/SiteForm.vue:397-402`).
+- `GET /` requires `requireOrgAccess` on the `org` filter the caller sends.
+- `GET /:id`, `PUT /:id` and `DELETE /:id` load the row first and decide from
+  the row's own `org` and `siteOrg` — Seven365 staff, or a live member of
+  EITHER side of the engagement. Either, not one: the estate's manager reaches
+  the row through `siteOrg` and the contracted agency reaches the same row
+  through `org`, so scoping to one side would break the other's screen.
+- `GET /service-provider/:id` takes a SITE id, and uses `entitleSite` — the
+  same site-reach rule the camera, HID and people modules already use, so an
+  agency contracted to a site still lists who else works there.
+
+`POST /invite/:id` is unchanged and still reachable with no session: an invited
+organisation accepts before it has an account (`web-app-main pages/sign-in.vue:182`).
+
+No new authorization mechanism is introduced. `requireOrgAccess` and
+`entitleSite` are the helpers the member, role, people, camera and HID paths
+already use, and the "either side" test is `resolveInviteActor` asked about two
+organisations in one round trip rather than two.

package/.changeset/site-org-scope.md

@@ -0,0 +1,46 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `/api/sites` to the organisation that owns the site.
+
+Every route on this router except the pre-login resident picker carried
+`requireAuth` and nothing more (`site.controller.ts`), and took the
+organisation from the query string or the site id from the URL. `requireAuth`
+proves a session exists and makes no organisation or site decision, so any
+signed-in account on the platform — a resident, a cleaner, an agency guard —
+could `DELETE /api/sites/:id` any site belonging to any client, rename it,
+re-block it, move its guard posts, rewrite its information page, create a site
+inside any organisation, and page through any client's estate list.
+
+The caller is now resolved from the session and the decision made before
+anything is read or written:
+
+- `POST /` uses `requireOrgAccess` on the body's `orgId` — that is where the new
+  site lands.
+- `GET /` uses `requireOrgAccess` on the `org` filter the caller sends.
+- `PUT /:id/block`, `PATCH /id/:id`, `PATCH /guard-post/id/:id`,
+  `PATCH /information/id/:id` and `DELETE /:id` use `entitleSite` — a
+  membership pinned to the site, an org-wide membership at the site's owning
+  organisation, or an ACTIVE `customer.sites` engagement. The engagement branch
+  is required, not incidental: Site Settings lives in the SERVICE-PROVIDER apps
+  (`web-app-security` and the five module apps, each
+  `pages/[org]/[site]/settings.vue` via `layer-common useSiteSettings.ts`), and
+  those users hold no membership in the estate's organisation at all.
+- `GET /:id` is deliberately one notch wider than the writes: it also passes
+  for any live membership in the site's OWNING organisation. Three shipped
+  mobile clients read this route, and the resident app reads
+  `org.defaultSite` — which in a multi-site organisation need not be the
+  resident's own site, and a resident's membership carries a `siteId`. The
+  wider read closes the cross-CLIENT read, which is the defect, and leaves
+  site-to-site partitioning inside one client where it is today.
+
+A site the caller cannot reach answers exactly as a site that does not exist,
+so site ids cannot be enumerated by watching the difference.
+
+`GET /site/resident` is unchanged and still pre-login: the resident mobile app
+needs a site picker before an account exists.
+
+No new authorization mechanism is introduced — `requireOrgAccess` and
+`entitleSite` are the helpers the member, role, people, camera and HID paths
+already use.

package/dist/index.d.ts

@@ -10153,7 +10153,6 @@ declare function useHidAmicoService(): {
         location?: string | undefined;
         enabled?: boolean | undefined;
         username: string;
-        serial?: string | undefined;
         capabilities?: {
             card: boolean;
             facial: boolean;
@@ -10161,6 +10160,7 @@ declare function useHidAmicoService(): {
             pin: boolean;
             intercom: boolean;
         } | undefined;
+        serial?: string | undefined;
         baseUrl: string;
         deviceId?: string | undefined;
         firmwareVersion?: string | undefined;