@7365admin1/core 3.48.1-staging.157 → 3.48.1-staging.159

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

@@ -0,0 +1,51 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the feedback routes to the estate the feedback was raised at, and take the
+author's identity from the session.
+
+A feedback row is a resident's complaint about their own estate: the subject,
+the free-text description, the location inside the block, the attachments and
+the name of the person who raised it. Every route on `/api/feedbacks` carried
+`requireAuth` and nothing more, and the controller held no authorization
+identifier of any kind, so being signed in anywhere on the platform was enough
+to read another client's complaints, rewrite them, re-route them to a different
+service line, close them, or delete them.
+
+`DELETE /:id` is the sharp one, twice over. It is the **only** route on this
+mount with a live caller — `layer-common`'s `useFeedback().deleteFeedback`,
+wired to the delete button in `FeedbackDetail.vue` and `FeedbackMain.vue`, which
+every web app draws — and it does not write to the v1 table at all. It writes to
+`feedbacks2`, the authoritative table every client reads. So the one reachable
+route on the legacy mount was an unguarded delete against live data. It is now
+checked against the `feedbacks2` row it actually touches, not the v1 row that
+happens to share the id.
+
+All eight routes go through `requireSiteReach`, the rule
+`/api/manpower-monitoring`, `/api/attendances`, `/api/remarks`,
+`/api/vehicles`, `/api/documents` and `/api/incident-reports` already use:
+
+- `GET /site/:site/status/:status` names the site in the URL, so it is checked
+  before the read.
+- The six record routes name only a record, so the site is read off the
+  **stored** row and a `site` in the caller's own body cannot stand in for it.
+  Two readers are needed, because the two tables are not the same shape: v1
+  `feedbacks` rows keep the site at `metadata.site`, `feedbacks2` rows keep it
+  at the top level.
+- `POST /` took the author from a `user` cookie the caller writes and never
+  compared it to the session, so a complaint could be filed in somebody else's
+  name. It comes from `callerId(req)` now, which also removes a latent crash:
+  `cookies?.["user"].toString()` short-circuits only on `cookies` being nullish
+  and threw on any request carrying cookies but no `user` cookie.
+
+`requireSiteReach` matters here because the contracted service provider that
+answers these complaints holds no membership in the estate's organisation and
+reaches it through `customer.sites`.
+
+Not fixed here, and reported separately: `POST /api/feedbacks` cannot succeed
+and could not before this change either. `feedback.service.ts` replaces
+`createdBy` with an `ObjectId` and `MFeedback` then re-validates the document
+against a schema where `createdBy` is `Joi.string().hex()`, so the create always
+answers 400. No client calls it — every client creates through
+`/api/feedbacks2`.

package/.changeset/work-order-site-scope.md

@@ -0,0 +1,77 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the work order routes to the estate the job was raised at, and take the
+author's identity from the session.
+
+A work order is a job at one estate: the subject, the description, the block and
+unit it sits in, the attachments, the assigned provider, and the name and
+signature captured when it is signed off. Every route on `/api/work-orders`
+carried `requireAuth` and nothing more, and `work-order.controller.ts` held no
+authorization identifier of any kind. `requireAuth` proves a session exists; it
+makes no organisation or site decision. So being signed in ANYWHERE on the
+platform was enough to read another client's jobs, rewrite them, drive them
+between columns, sign them off in a stranger's name, or delete them.
+
+`DELETE /:id` is the sharp one, and for the same reason it was sharp on
+`/api/feedbacks`: **it does not write to the v1 table at all.** `deleteWorkOrder`
+in `work-order.repo.ts` updates `workOrders2Collection` — `work-orders2`, the
+authoritative table every client actually reads. A guard written against the v1
+row would have been the wrong guard, so this one is written against the row the
+write really touches. `DELETE /:id` and `PUT /:id` are also the only two routes
+on this mount with a live caller: `layer-common`'s
+`useWorkOrder().deleteWorkOrder` and `updateWorkOrder`, behind the shared
+`WorkOrder/Main.vue` and `WorkOrder/Detail.vue` screens that every web app draws.
+
+All seven handlers now decide before any work is done:
+
+- `GET /site/:site/status/:status` names the site in the URL, so it is checked
+  directly with `requireSiteReach`.
+- `GET /:id`, `PUT /:id`, `PUT /:id/:status` and `PATCH /:id/completed` name only
+  a record, so the site is read off the STORED row through the new
+  `requireWorkOrderReach`. A `site` in the caller's own body or query cannot
+  stand in for it.
+- `DELETE /:id` uses `requireWorkOrder2Reach`, against the `work-orders2` row.
+- `POST /` reads the destination from the body.
+
+Two readers were needed, not one, because the tables are not the same shape: v1
+`work-orders` rows keep the site at `metadata.site`, `work-orders2` rows keep it
+at the top level. Both are new raw readers on the repository —
+`getRawWorkOrderById` and `getRawWorkOrder2ById`. The existing `getWorkOrderById`
+is CACHED and shaped for the screen, so a reach check built on it would have
+decided who may touch a job from a cache entry.
+
+Two further defects fixed in the same pass:
+
+1. **Identity from a cookie the caller writes.** `POST /` parsed `createdBy` out
+   of the raw `Cookie` header and never compared it to the session, so a job
+   could be raised in somebody else's name. It comes from `callerId(req)` now.
+   That also closes a latent crash: `cookies?.["user"].toString()`
+   short-circuits only on `cookies` being nullish, so any request carrying
+   cookies but no `user` cookie threw a TypeError.
+2. **A body that names the site twice, with unequal weight.** `POST /` accepts
+   `metadata.site` AND a top-level `site`, and `work-order.service.ts` copies the
+   top-level one OVER `metadata.site` (`if (value.site) value.metadata.site =
+   value.site`). A caller could therefore name their own estate in `metadata`
+   while the row landed at somebody else's. The guard reads them in the order the
+   service resolves them.
+
+`PUT /:id` is a write that can MOVE a record — the repository `$set`s whatever
+the body carries, including `site` — so the DESTINATION is checked as well as the
+origin. Without that, a legacy row carrying no `metadata.site` could be given a
+top-level `site` of the caller's own and become theirs.
+
+Each guard is placed AFTER the handler's own Joi validation, so a malformed id
+still answers 400 exactly as before. A row that does not exist has no site, and
+`requireSiteReach` refuses a missing site, so an id matching nothing is refused
+rather than falling through.
+
+The rule is the existing one, `requireSiteReach` -> `entitleSite`, already used
+by `/api/feedbacks`, `/api/manpower-monitoring`, `/api/attendances`,
+`/api/remarks`, `/api/vehicles`, `/api/documents` and `/api/incident-reports`.
+The `customer.sites` branch is required, not incidental: the contracted provider
+that does this work holds no membership in the estate's own organisation.
+
+`/api/work-orders2` is a different mount, lives in API-core's own controller, and
+is not touched here.

package/dist/index.d.ts

@@ -1621,6 +1621,8 @@ declare function useFeedbackRepo(): {
         pageRange: string;
     }>;
     getFeedbackById: (_id: string | ObjectId) => Promise<bson.Document>;
+    getRawFeedbackById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
+    getRawFeedback2ById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
     updateFeedback: (_id: string | ObjectId, value: TFeedbackUpdate) => Promise<number>;
     updateFeedbackStatus: (_id: string | ObjectId, value: TFeedbackUpdateStatus) => Promise<number>;
     updateFeedbackCreatedByName: (_id: string | ObjectId, value: string | ObjectId, session?: ClientSession) => Promise<number>;
@@ -1649,6 +1651,46 @@ declare function useFeedbackService(): {
     }>;
 };
 
+/**
+ * Who may see, or change, a site's feedback.
+ *
+ * A feedback row is a resident's complaint about their own estate - the
+ * subject, the free-text description, the location inside the block, the
+ * attachments, and the name of the person who raised it. Every route on
+ * `/api/feedbacks` 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 client's complaints, re-categorise
+ * them, mark them completed, or delete them.
+ *
+ * `DELETE /:id` is the sharp one, for two reasons. It is the ONLY route on this
+ * mount with a live caller - `layer-common`'s `useFeedback().deleteFeedback`,
+ * wired to the delete button in `FeedbackDetail.vue` and `FeedbackMain.vue`,
+ * which every web app draws - and it does not write to the v1 table at all. It
+ * writes to `feedbacks2`, the authoritative one every client reads. So the one
+ * reachable route on the legacy mount was an unguarded delete against live
+ * data. It is guarded here against the row it actually touches.
+ *
+ * The estate is the scope. `requireSiteReach` is the rule
+ * `/api/manpower-monitoring`, `/api/attendances`, `/api/remarks`,
+ * `/api/vehicles`, `/api/documents` and `/api/incident-reports` already use, so
+ * the contracted agency that answers these complaints reaches the estate
+ * through `customer.sites` and needs no membership in its organisation.
+ *
+ *  - `GET /site/:site/status/:status` names the site in the URL, so it is
+ *    checked before the read.
+ *  - The six record routes name only a record, so the site is read off the
+ *    STORED row and a `site` in the caller's own body cannot stand in for it.
+ *  - `POST /` took the author's identity from a `user` cookie the caller writes
+ *    and never compared it to the session, so a feedback could be filed in
+ *    somebody else's name. It comes from `callerId(req)` now - which also
+ *    removes a latent crash, because `cookies?.["user"].toString()`
+ *    short-circuits only on `cookies` being nullish and threw on any request
+ *    that carried cookies but no `user` cookie.
+ *
+ * Two readers, not one, because the two tables are not the same shape: v1
+ * `feedbacks` rows keep the site at `metadata.site`, `feedbacks2` rows keep it
+ * at the top level.
+ */
 declare function useFeedbackController(): {
     createFeedback: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getFeedbacks: (req: Request, res: Response, next: NextFunction) => Promise<void>;
@@ -1755,6 +1797,8 @@ declare function useWorkOrderRepo(): {
         category?: string | undefined;
     }) => Promise<{}>;
     getWorkOrderById: (_id: string | ObjectId) => Promise<{}>;
+    getRawWorkOrderById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
+    getRawWorkOrder2ById: (_id: string | ObjectId) => Promise<mongodb.WithId<bson.Document> | null>;
     updateWorkOrder: (_id: string | ObjectId, value: TWorkOrderUpdate) => Promise<number>;
     updateWorkOrderStatus: (_id: string | ObjectId, value: TWorkOrderUpdateStatus) => Promise<number>;
     updateWorkOrderCreatedByName: (_id: string | ObjectId, value: string | ObjectId, session?: ClientSession) => Promise<number>;
@@ -1776,6 +1820,55 @@ declare function useWorkOrderService(): {
     }) => Promise<{}>;
 };
 
+/**
+ * Who may see, or change, a site's work orders.
+ *
+ * A work order is a job raised at one estate - the subject, the description,
+ * the block and unit it sits in, the attachments, the assigned provider, and
+ * the name and signature captured when it is signed off. Every route on
+ * `/api/work-orders` 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 client's jobs, edit
+ * them, drive their status, sign them off in a stranger's name, or delete them.
+ *
+ * `DELETE /:id` is the sharp one, and for the same reason it was sharp on
+ * `/api/feedbacks`: it does not write to the v1 table at all. `deleteWorkOrder`
+ * in the repository updates `workOrders2Collection` - `work-orders2`, the
+ * authoritative table every client actually reads. A guard written against the
+ * v1 row would have been the wrong guard, so this one is written against the
+ * row the write really touches.
+ *
+ * The estate is the scope. `requireSiteReach` is the rule `/api/feedbacks`,
+ * `/api/manpower-monitoring`, `/api/attendances`, `/api/remarks`,
+ * `/api/vehicles`, `/api/documents` and `/api/incident-reports` already use, so
+ * the contracted provider that does this work reaches the estate through
+ * `customer.sites` and needs no membership in its organisation.
+ *
+ *  - `GET /site/:site/status/:status` names the site in the URL, so it is
+ *    checked before the read.
+ *  - The five record routes name only a record, so the site is read off the
+ *    STORED row and a `site` in the caller's own body cannot stand in for it.
+ *  - `POST /` names the site in the body - possibly twice. `metadata.site`
+ *    and a top-level `site` are not equal: the service copies the top-level one
+ *    OVER `metadata.site`, so the guard reads them in that order and a caller
+ *    cannot name their own site at the top level while the row lands somewhere
+ *    else. A create naming no site at all is refused.
+ *  - `POST /` also took the author's identity from a `user` cookie the caller
+ *    writes and never compared it to the session, so a job could be raised in
+ *    somebody else's name. It comes from `callerId(req)` now - which also
+ *    removes a latent crash, because `cookies?.["user"].toString()`
+ *    short-circuits only on `cookies` being nullish and threw on any request
+ *    that carried cookies but no `user` cookie.
+ *  - `PUT /:id` accepts `site` and `organization` in the body and the
+ *    repository `$set`s them, so where the body names a destination it is
+ *    checked as well as the origin. That closes the one way the fallback below
+ *    could be walked: a legacy row with no `metadata.site` would otherwise let
+ *    a caller write a top-level `site` of their own and make the row reachable.
+ *
+ * Two readers, not one, because the two tables are not the same shape: v1
+ * `work_orders` rows keep the site at `metadata.site`, `work-orders2` rows keep
+ * it at the top level.
+ */
 declare function useWorkOrderController(): {
     createWorkOrder: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getWorkOrders: (req: Request, res: Response, next: NextFunction) => Promise<void>;

package/dist/index.js

@@ -7188,6 +7188,22 @@ function useFeedbackRepo() {
       throw error;
     }
   }
+  async function getRawFeedbackById(_id) {
+    try {
+      _id = new import_mongodb4.ObjectId(_id);
+    } catch (error) {
+      throw new import_node_server_utils5.BadRequestError("Invalid feedback ID format.");
+    }
+    return await collection.findOne({ _id });
+  }
+  async function getRawFeedback2ById(_id) {
+    try {
+      _id = new import_mongodb4.ObjectId(_id);
+    } catch (error) {
+      throw new import_node_server_utils5.BadRequestError("Invalid feedback ID format.");
+    }
+    return await feedbacks2Collection.findOne({ _id });
+  }
   async function updateFeedback(_id, value) {
     try {
       _id = new import_mongodb4.ObjectId(_id);
@@ -7414,6 +7430,8 @@ function useFeedbackRepo() {
     createFeedback,
     getFeedbacks,
     getFeedbackById,
+    getRawFeedbackById,
+    getRawFeedback2ById,
     updateFeedback,
     updateFeedbackStatus,
     updateFeedbackCreatedByName,
@@ -7837,6 +7855,22 @@ function useWorkOrderRepo() {
       throw error;
     }
   }
+  async function getRawWorkOrderById(_id) {
+    try {
+      _id = new import_mongodb6.ObjectId(_id);
+    } catch (error) {
+      throw new import_node_server_utils7.BadRequestError("Invalid work order ID format.");
+    }
+    return await collection.findOne({ _id });
+  }
+  async function getRawWorkOrder2ById(_id) {
+    try {
+      _id = new import_mongodb6.ObjectId(_id);
+    } catch (error) {
+      throw new import_node_server_utils7.BadRequestError("Invalid work order ID format.");
+    }
+    return await workOrders2Collection.findOne({ _id });
+  }
   async function updateWorkOrder(_id, value) {
     try {
       _id = new import_mongodb6.ObjectId(_id);
@@ -8028,6 +8062,8 @@ function useWorkOrderRepo() {
     createWorkOrder,
     getWorkOrders,
     getWorkOrderById,
+    getRawWorkOrderById,
+    getRawWorkOrder2ById,
     updateWorkOrder,
     updateWorkOrderStatus,
     updateWorkOrderCreatedByName,
@@ -31708,18 +31744,24 @@ function useFeedbackController() {
   const { createFeedback: _createFeedback, getFeedbacks: _getFeedbacks } = useFeedbackService();
   const {
     getFeedbackById: _getFeedbackById,
+    getRawFeedbackById: _getRawFeedbackById,
+    getRawFeedback2ById: _getRawFeedback2ById,
     updateFeedback: _updateFeedback,
     updateFeedbackStatus: _updateFeedbackStatus,
     updateFeedbackCategory: _updateFeedbackCategory,
     updateFeedbackToCompleted: _updateFeedbackToCompleted,
     deleteFeedback: _deleteFeedback
   } = useFeedbackRepo();
+  async function requireFeedbackReach(req, _id) {
+    const row = await _getRawFeedbackById(_id);
+    await requireSiteReach(req, row?.metadata?.site ?? row?.site);
+  }
+  async function requireFeedback2Reach(req, _id) {
+    const row = await _getRawFeedback2ById(_id);
+    await requireSiteReach(req, row?.site ?? row?.metadata?.site);
+  }
   async function createFeedback(req, res, next) {
-    const cookies = req.headers.cookie?.split(";").map((cookie) => cookie.trim().split("=")).reduce(
-      (acc, [key, value]) => ({ ...acc, [key]: value }),
-      {}
-    );
-    const createdBy = cookies?.["user"].toString() ?? "";
+    const createdBy = callerId(req);
     const payload = { ...req.body, createdBy };
     const { error } = feedbackSchema.validate(payload);
     if (error) {
@@ -31728,6 +31770,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireSiteReach(req, payload.metadata?.site ?? payload.site);
       await _createFeedback(payload);
       res.status(201).json({ message: "Successfully created feedback." });
       return;
@@ -31768,6 +31811,7 @@ function useFeedbackController() {
     const to = req.query.to ?? "";
     const category = req.query.category ?? "";
     try {
+      await requireSiteReach(req, site);
       const data = await _getFeedbacks({
         search,
         page,
@@ -31797,6 +31841,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireFeedbackReach(req, _id);
       const data = await _getFeedbackById(_id);
       res.json(data);
       return;
@@ -31825,6 +31870,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireFeedbackReach(req, _id);
       await _updateFeedback(_id, payload);
       res.json({ message: "Successfully updated feedback." });
       return;
@@ -31849,6 +31895,7 @@ function useFeedbackController() {
     const _id = req.params.id;
     const status = req.params.status;
     try {
+      await requireFeedbackReach(req, _id);
       await _updateFeedbackStatus(_id, { status });
       res.json({ message: "Successfully updated feedback status." });
       return;
@@ -31872,6 +31919,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireFeedbackReach(req, _id);
       await _updateFeedbackCategory(_id, { category });
       res.json({ message: "Successfully updated feedback category." });
       return;
@@ -31897,6 +31945,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireFeedbackReach(req, _id);
       await _updateFeedbackToCompleted(_id, payload);
       res.json({ message: "Successfully updated feedback to completed." });
       return;
@@ -31916,6 +31965,7 @@ function useFeedbackController() {
       return;
     }
     try {
+      await requireFeedback2Reach(req, _id);
       await _deleteFeedback(_id);
       res.json({ message: "Successfully deleted feedback." });
       return;
@@ -32096,17 +32146,23 @@ function useWorkOrderController() {
   const { createWorkOrder: _createWorkOrder, getWorkOrders: _getWorkOrders } = useWorkOrderService();
   const {
     getWorkOrderById: _getWorkOrderById,
+    getRawWorkOrderById: _getRawWorkOrderById,
+    getRawWorkOrder2ById: _getRawWorkOrder2ById,
     updateWorkOrder: _updateWorkOrder,
     updateWorkOrderStatus: _updateWorkOrderStatus,
     updateWorkOrderToCompleted: _updateWorkOrderToCompleted,
     deleteWorkOrder: _deleteWorkOrder
   } = useWorkOrderRepo();
+  async function requireWorkOrderReach(req, _id) {
+    const row = await _getRawWorkOrderById(_id);
+    await requireSiteReach(req, row?.metadata?.site ?? row?.site);
+  }
+  async function requireWorkOrder2Reach(req, _id) {
+    const row = await _getRawWorkOrder2ById(_id);
+    await requireSiteReach(req, row?.site ?? row?.metadata?.site);
+  }
   async function createWorkOrder(req, res, next) {
-    const cookies = req.headers.cookie?.split(";").map((cookie) => cookie.trim().split("=")).reduce(
-      (acc, [key, value]) => ({ ...acc, [key]: value }),
-      {}
-    );
-    const createdBy = cookies?.["user"].toString() ?? "";
+    const createdBy = callerId(req);
     const payload = { ...req.body, createdBy };
     const { error } = workOrderSchema.validate({ ...payload });
     if (error) {
@@ -32116,6 +32172,7 @@ function useWorkOrderController() {
     }
     const fullHost = req.headers.origin;
     try {
+      await requireSiteReach(req, payload.site || payload.metadata?.site);
       const workOrder = await _createWorkOrder(payload, fullHost);
       res.status(201).json({
         message: "Successfully created work order.",
@@ -32156,6 +32213,7 @@ function useWorkOrderController() {
     const serviceProvider = req.query.serviceProvider ?? "";
     const category = req.query.category ?? "";
     try {
+      await requireSiteReach(req, site);
       const data = await _getWorkOrders({
         search,
         page,
@@ -32183,6 +32241,7 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrderReach(req, _id);
       const data = await _getWorkOrderById(_id);
       res.json(data);
       return;
@@ -32214,6 +32273,10 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrderReach(req, _id);
+      if (payload.site) {
+        await requireSiteReach(req, payload.site);
+      }
       await _updateWorkOrder(_id, payload);
       res.json({ message: "Successfully updated work order." });
       return;
@@ -32237,6 +32300,7 @@ function useWorkOrderController() {
     const _id = req.params.id;
     const status = req.params.status;
     try {
+      await requireWorkOrderReach(req, _id);
       await _updateWorkOrderStatus(_id, { status });
       res.json({ message: "Successfully updated work order status." });
       return;
@@ -32262,6 +32326,7 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrderReach(req, _id);
       await _updateWorkOrderToCompleted(_id, payload);
       res.json({ message: "Successfully updated work order to completed." });
       return;
@@ -32280,6 +32345,7 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrder2Reach(req, _id);
       await _deleteWorkOrder(_id);
       res.json({ message: "Successfully deleted work order." });
       return;