@7365admin1/core 3.48.1-staging.168 → 3.48.1-staging.170

package/.changeset/provider-billing-org-scope.md

@@ -0,0 +1,21 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope the service provider billing routes to the organisation
+
+`/api/provider-billings` carried `requireAuth` and nothing more on all five
+handlers, and `service-provider-billing.controller.ts` held no authorization
+identifier of any kind. A service provider billing record is what a contractor
+invoices an organisation for, so any signed-in account on the platform could
+read another organisation's invoices, swap the attachments that evidence one,
+flip its status, add an acknowledgement that was never given, or delete it.
+
+The scope here is the ORGANISATION, not the estate: every row carries `orgId`
+and no `site`, so the rule is `requireOrgAccess` — Seven365 staff, or a live
+member of that organisation — not `requireSiteReach`.
+
+Adds `requireServiceProviderBillingReach`, plus an uncached
+`getRawServiceProviderBillingById` so the check is not decided from a 15-minute
+cache entry (the existing reader is cached and throws `NotFoundError`, which
+would also answer before the guard ran).

package/.changeset/site-unit-billing-scope.md

@@ -0,0 +1,25 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope the unit billing routes to the estate, and the resident routes to the caller's own unit
+
+`/api/site-unit-billing` carried `requireAuth` and nothing more on all seven
+handlers, and `site-unit-billing.controller.ts` held no authorization identifier
+of any kind. Two separate problems followed.
+
+On the estate side, any signed-in account could add a bill to any estate, read
+another estate's whole billing run, restate what a resident owes, move a bill to
+another estate, or delete it. Those five routes now use `requireSiteReach`, plus
+a new `requireUnitBillingReach` on the stored row and an uncached
+`getRawUnitBillingById`. `PUT /id/:id` checks both ends, because
+`schemaUpdateSiteUnitBilling` accepts `site` and `updateById` writes it.
+
+On the resident side, `GET /user` and `GET /user/unsettled` are named for the
+signed-in resident but took `site` and `unitId` from the QUERY and identified the
+caller not at all, so they were never "my bills" — they were any unit's bills at
+any estate. A resident passing a neighbour's unit id got the neighbour's
+maintenance bills, and omitting `unitId` dropped that filter too and returned the
+whole estate's. Both routes now require `unitId` and check it against a live
+`people` row joining the caller to that unit at that site, via a new
+`requireOwnUnit`. Seven365 platform staff are exempt.

package/dist/index.d.ts

@@ -5438,6 +5438,7 @@ declare function useServiceProviderBillingRepo(): {
         pageRange: string;
     } | TServiceProviderBilling>;
     getSiteServiceProviderBillingById: (_id: string | ObjectId, session?: ClientSession) => Promise<mongodb.WithId<bson.Document> | TServiceProviderBilling>;
+    getRawServiceProviderBillingById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
     updateServiceProviderBillingById: (_id: ObjectId | string, value: Partial<TServiceProviderBilling>, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
     deleteServiceProviderBillingById: (_id: string | ObjectId) => Promise<number>;
     createIndexes: () => Promise<void>;
@@ -5448,6 +5449,36 @@ declare function useServiceProviderBillingService(): {
     updateServiceProviderBillingById: (id: string | ObjectId, value: Partial<TServiceProviderBilling>) => Promise<string>;
 };
 
+/**
+ * Who may see, or change, a service provider's billing records.
+ *
+ * A service provider billing record is what a contractor invoices an
+ * organisation for - the amount, the period, the attachments that evidence it,
+ * and the people who acknowledged it. It is money.
+ *
+ * All five routes on `/api/provider-billings` carried `requireAuth` and nothing
+ * more, and this controller held no authorization identifier of any kind, so
+ * being signed in ANYWHERE on the platform was enough to read another
+ * organisation's invoices, restate one, replace its evidence, or delete it.
+ *
+ * The scope here is the ORGANISATION, not the estate. Every row carries
+ * `orgId` and no `site` - `getAll` is asked for an `org`, and the repository
+ * builds `{ orgId: org, status }`. So the rule is `requireOrgAccess`, the same
+ * one `/api/customer-sites` and `/api/members` already use: Seven365 staff, or
+ * a live member of that organisation. Using `requireSiteReach` here would be
+ * asking the wrong question of the wrong field.
+ *
+ *  - `POST /` already REQUIRES `orgId` in the body and `GET /` already REQUIRES
+ *    `org` in the query, so the guard checks the organisation the request
+ *    already names and no caller's contract changes.
+ *  - The three record routes name only a record, so the organisation is read
+ *    off the STORED row via `requireServiceProviderBillingReach`, and an
+ *    `orgId` in the caller's own body cannot stand in for it.
+ *
+ * `PUT /id/:id` cannot MOVE a record between organisations:
+ * `schemaUpdateServiceProviderBilling` does not accept `orgId` at all, so there
+ * is no destination to check.
+ */
 declare function useServiceProviderBillingController(): {
     add: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getAll: (req: Request, res: Response, next: NextFunction) => Promise<void>;
@@ -6227,6 +6258,7 @@ declare function useSiteUnitBillingRepo(): {
         dateTo?: string | undefined;
     }, session?: ClientSession) => Promise<{}>;
     getById: (_id: string | ObjectId) => Promise<TUnitBilling | null>;
+    getRawUnitBillingById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
     updateById: (_id: string | ObjectId, value: Partial<TUnitBilling>, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
     deleteById: (_id: string | ObjectId) => Promise<number>;
     getUnitBillingBySite: ({ status, site, dateFrom, dateTo, unitId, }: {
@@ -6276,6 +6308,39 @@ declare function useSiteUnitBillingService(): {
     checkOverDueBills: () => Promise<"No overdue bills found." | "Successfully checked and updated overdue bills.">;
 };
 
+/**
+ * Who may see, or change, a unit's maintenance bills.
+ *
+ * A site unit billing row is one unit's bill for a period - the amount, what is
+ * outstanding, what has been paid, and against which billing item. It is money,
+ * and on the resident side it is somebody's household finances.
+ *
+ * All seven routes on `/api/site-unit-billing` carried `requireAuth` and
+ * nothing more, and this controller held no authorization identifier of any
+ * kind, so being signed in ANYWHERE on the platform was enough to read another
+ * estate's billing run, restate a bill, move it to another estate, or delete
+ * it.
+ *
+ * The two resident routes are the sharp ones and are guarded differently from
+ * the rest - see `requireOwnUnit`. `GET /user` and `GET /user/unsettled` are
+ * named for the signed-in resident but took `site` and `unitId` from the QUERY
+ * and identified the caller not at all, so they were never "my bills": they
+ * were "any unit's bills, at any estate". A resident passing a NEIGHBOUR's unit
+ * id got the neighbour's maintenance bills, and omitting `unitId` dropped that
+ * filter as well.
+ *
+ * For the five estate-side routes the scope is the estate, and `requireSiteReach`
+ * is the rule `/api/patrol-logs`, `/api/feedbacks`, `/api/work-orders` and
+ * `/api/occurrence-books` already use.
+ *
+ *  - `POST /` and `GET /` name a site, so the guard checks the site the request
+ *    already names.
+ *  - The three record routes name only a record, so the site is read off the
+ *    STORED row via `requireUnitBillingReach`.
+ *
+ * `PUT /id/:id` CAN move a bill: `schemaUpdateSiteUnitBilling` accepts `site`
+ * and `updateById` writes it, so both ends are checked.
+ */
 declare function useSiteUnitBillingController(): {
     add: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getAll: (req: Request, res: Response, next: NextFunction) => Promise<void>;