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

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

@@ -1797,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>;
@@ -1818,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

@@ -7855,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);
@@ -8046,6 +8062,8 @@ function useWorkOrderRepo() {
     createWorkOrder,
     getWorkOrders,
     getWorkOrderById,
+    getRawWorkOrderById,
+    getRawWorkOrder2ById,
     updateWorkOrder,
     updateWorkOrderStatus,
     updateWorkOrderCreatedByName,
@@ -32128,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) {
@@ -32148,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.",
@@ -32188,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,
@@ -32215,6 +32241,7 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrderReach(req, _id);
       const data = await _getWorkOrderById(_id);
       res.json(data);
       return;
@@ -32246,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;
@@ -32269,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;
@@ -32294,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;
@@ -32312,6 +32345,7 @@ function useWorkOrderController() {
       return;
     }
     try {
+      await requireWorkOrder2Reach(req, _id);
       await _deleteWorkOrder(_id);
       res.json({ message: "Successfully deleted work order." });
       return;