@7365admin1/core 3.52.2 → 3.52.3-staging.243

package/.changeset/camera-error-wording-and-plate-cleanup.md

@@ -0,0 +1,11 @@
+---
+"@7365admin1/core": patch
+---
+
+Write camera failures in words an operator can act on, and stop offering plates whose vehicle has been deleted.
+
+Camera failure messages no longer carry a camera's `_id`, its host, an IP, a port or a raw driver error. A camera is named by its display name and direction ("North Gate (entry)", or "the entry camera" when it has no name), and the reason is plain language ("the camera could not be reached"). The full technical detail — record id, host, and the device's or driver's own text — goes to the server log instead. The same treatment is applied to create, approve, restore, block, unblock, edit and delete; `blocklistVehicles`, `removeFromBlocklist` and `reactivateVehicleById` previously said only "Failed to delete/update/add plate number to ANPR", which named no camera and said nothing about what happened to the record. Blocking now states the opposite consequence to saving, because a failed blacklist write leaves the car able to get in.
+
+`site.people.plates[]` no longer keeps a plate after its vehicle is deleted. The pull matched on `recNo`, which Dahua numbers per device, so the copy on the vehicle and the copy on the person diverged and the update silently matched nothing; it now matches on the plate number, and leaves the plate alone when a second live vehicle still holds it. Unblocking, which soft-deletes the record, now pulls the plate too. `GET /api/people/unit/:unit` and `GET /api/people` also drop any plate whose vehicle records are all deleted, so rows that had already drifted are not offered either. A plate the resident merely declared, with no vehicle record at all, is unchanged.
+
+Unblocking a vehicle at a site with no ANPR camera now succeeds instead of failing with "No site cameras found." — there is nothing to revoke, which is the state the unblock is trying to reach. Approve, Restore, Block and Edit still refuse in that state, now saying why and what did not happen.

package/.changeset/plate-lookup-hides-deleted-plates.md

@@ -0,0 +1,9 @@
+---
+"@7365admin1/core": patch
+---
+
+`GET /api/people/plateNumber/:plateNumber` now hides plates whose vehicle has been deleted, like the other person reads.
+
+Its own filter is `status: { $ne: "deleted" }` on the **person**, which is unrelated to the vehicle — reading that line as "deleted plates are excluded" is why this endpoint was missed when the other two were fixed. It has no caller in the estate today, but it is routed and behind `requireAuth`, so an authenticated caller gets the resident's whole `plates[]` array back. The filter runs on read, after the cache, because whether a plate's vehicle is deleted can change inside the 15-minute TTL.
+
+`getPersonByPlateNumber` (no caller, no route) and `getApprovedPersonByPlateNumber` (a record-matching path inside `person.service.ts`, not a display path) are deliberately left alone.

package/.changeset/plates-hidden-on-all-person-reads.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": patch
+---
+
+Hide deleted plates on every person read, not only on the two browse paths.
+
+A vehicle's plate number is copied onto the resident's record as `site.people.plates[]`. Deleting the vehicle is meant to take it back out, and where that copy had already drifted the read paths filter it against the vehicle record. That filter was only on `GET /api/people` and `GET /api/people/unit/:unit`, so four other endpoints still handed back a plate whose only vehicle is deleted:
+
+- `GET /api/people/plateNumber/:plateNumber`
+- `GET /api/people/nric/:nric` (the MA app's NRIC lookup, and layer-common's `findPersonByNRIC`)
+- `GET /api/people/contact/:contact`
+- `GET /api/people/all-nric` (the MA app's NRIC search)
+
+Each of the four now applies the same filter. `status: { $ne: "deleted" }` on three of those queries is the PERSON's status and has nothing to do with the vehicle — reading it as "deleted plates are excluded" is how they were missed. The filter runs on the way out, after the Redis read, so a plate deleted inside the 15-minute cache window disappears immediately rather than at the next expiry.
+
+Unchanged: a plate the resident merely declared, with no vehicle record at all, is still listed; a plate a second live vehicle still holds is still listed.

package/dist/index.d.ts

@@ -2528,6 +2528,14 @@ type AnprRevokeOutcome = {
     statusCode?: number;
     /** Why it failed, in words an operator can act on. Empty when `ok`. */
     reason: string;
+    /**
+     * The technical cause, for the SERVER LOG only. Never rendered.
+     *
+     * `reason` used to BE this string, so a driver error went straight to the
+     * browser: "connect EHOSTUNREACH 129.126.212.21:8081" put an internal IP and
+     * port in front of a condo manager, who can do nothing with either.
+     */
+    detail?: string;
 };
 
 declare enum CameraType {
@@ -5048,7 +5056,13 @@ declare function usePersonRepo(): {
         nric?: string | undefined;
         sort?: Record<string, any> | undefined;
         site: string;
-    }) => Promise<{}>;
+    }) => Promise<{
+        items: any[];
+        pages: number;
+        pageRange: string;
+    } | {
+        items: TPerson[];
+    }>;
     pushVehicleById: (id: string | ObjectId, plate: {
         plateNumber: string;
         recNo: string;