@7365admin1/core 3.48.1-staging.169 → 3.48.1-staging.171

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

@@ -0,0 +1,30 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope the statement of account routes to the estate and the unit, and take the requester and approver from the session
+
+Eight of the nine routes on `/api/site-soa` carried `requireAuth` and nothing
+more, and `site-soa.controller.ts` held no authorization identifier of any kind.
+A statement of account is one unit's ledger for a period, so any signed-in
+account on the platform could read another estate's statements, restate one,
+approve or reject it, move it to another estate, or delete it.
+
+`GET /user` is named for the signed-in resident but took `site` and `unitId`
+from the query and identified the caller not at all, so a resident could read a
+neighbour's statement of account by changing one id in a URL. It now requires
+`unitId` and checks it against a live `people` row joining the caller to that
+unit, via `requireOwnUnit`.
+
+`add` set `createdBy`, and `reviewSOA` set `approvedBy._id`, by parsing the raw
+`user` cookie off the request, so a statement could be requested under another
+resident's name and approved under another person's. Both now come from
+`callerId(req)`.
+
+Adds `requireStatementReach` plus an uncached `getRawStatementOfAccountById`.
+`PUT /id/:id` checks both ends, because `schemaUpdateStatementOfAccount` accepts
+`site` and `updateById` writes it.
+
+`GET /generate-pdf` is deliberately unchanged: it is the platform's PDF service,
+called from every web app by `@7365admin1/layer-common`'s `usePDFDownload`, and
+it is authorized by forwarding the caller's own session to the headless browser.

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

@@ -6258,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, }: {
@@ -6307,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>;
@@ -7170,6 +7204,7 @@ declare function useStatementOfAccountRepo(): {
         dateTo?: string | undefined;
     }, session?: ClientSession) => Promise<{}>;
     getById: (_id: string | ObjectId) => Promise<TStatementOfAccount | null>;
+    getRawStatementOfAccountById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
     updateById: (_id: string | ObjectId, value: Partial<TStatementOfAccount>, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
     deleteById: (_id: string | ObjectId) => Promise<number>;
     updateStatusById: (_id: string | ObjectId, value: Pick<TStatementOfAccount, "status">, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
@@ -7193,6 +7228,43 @@ declare function useStatementOfAccountRepo(): {
     createIndexes: () => Promise<string>;
 };
 
+/**
+ * Who may see, or change, a statement of account.
+ *
+ * A statement of account is one unit's ledger for a period - every charge and
+ * every payment on a household's account, requested by the resident and
+ * approved by the estate. It is money, and on the resident side it is somebody
+ * else's household finances.
+ *
+ * Eight of the nine routes on `/api/site-soa` 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
+ * statements, restate one, approve or reject it, move it to another estate, or
+ * delete it.
+ *
+ * Three distinct problems, and they need three different answers.
+ *
+ * 1. THE ESTATE SIDE. `POST /` and `GET /` name a site, so the guard checks the
+ *    site the request already names. The four record routes name only a record,
+ *    so the site is read off the STORED row via `requireStatementReach`, and a
+ *    `site` in the caller's own body cannot stand in for it. `PUT /id/:id` CAN
+ *    move a statement - `schemaUpdateStatementOfAccount` accepts `site` and
+ *    `updateById` writes it - so both ends are checked.
+ *
+ * 2. THE RESIDENT SIDE. `GET /user` is named for the signed-in resident but
+ *    took `site` and `unitId` from the QUERY and identified the caller not at
+ *    all, so it was never "my statements": it was any unit's, at any estate.
+ *    `requireOwnUnit` asks the question the data already answers - is there a
+ *    live `people` row joining this caller to this unit at this site?
+ *
+ * 3. IDENTITY FROM THE REQUEST. `add` set `createdBy` and `reviewSOA` set
+ *    `approvedBy._id` by parsing the raw `user` COOKIE off the request, so a
+ *    statement could be requested under another resident's name and, worse,
+ *    APPROVED under another person's. Both now come from `callerId(req)`.
+ *
+ * `GET /generate-pdf` is deliberately NOT scoped here - see the note on the
+ * handler.
+ */
 declare function useStatementOfAccountController(): {
     add: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getAll: (req: Request, res: Response, next: NextFunction) => Promise<void>;