@7365admin1/core 3.52.3-staging.248 → 3.52.4

package/CHANGELOG.md

@@ -1,5 +1,109 @@
 # @iservice365/core
 
+## 3.52.4
+
+### Patch Changes
+
+- c533662: Stop silently discarding a bulletin whose recipients include a service app with no users.
+
+  `POST /api/bulletin-boards` inserts the announcement inside a Mongo transaction and then
+  notifies each recipient group. The five per-service-app blocks each carried a bare `return;` for
+  "this site has no id" and "this app has no registered users". Those returns left the enclosing
+  `try` before `commitTransaction()`, so the session was ended with the transaction still open and
+  the announcement was rolled back — while the controller still answered `201 Created`. Selecting
+  Cleaning, M&E, Pest Control, Landscaping or Pool Maintenance at an estate with no users of that
+  app therefore made the announcement vanish with no error anywhere.
+
+  The five blocks are now one loop over a recipient-to-app-slug map, and a missing push audience
+  skips one notification instead of ending the request. Same apps, same order, same payloads.
+
+- ad056fb: Stop the bulletin-board expiry sweep from overwriting deleted announcements
+
+  `processExpiredBulletinBoards` runs hourly and matched on the dates alone:
+  `{ noExpiration: false, endDate: { $lt: now } }`. A soft delete only rewrites
+  `status` and `deletedAt` - the row keeps its start and end dates - so every
+  deleted announcement whose end date had passed matched the sweep, and its
+  `status: "deleted"` was overwritten with `status: "expired"`. The announcement
+  then reappeared on the Expired tab, and the user who deleted it saw it come
+  back.
+
+  Measured read-only on staging: of 63 rows carrying a real `deletedAt`, only 33
+  still read `deleted` - 30 (48%) had been flipped to `expired` by the sweep.
+
+  The query now excludes `status: "deleted"`. It lives in the model next to
+  `deriveBulletinStatus` as `expiredBulletinSweepFilter`, so the rule the sweep
+  uses is the same one create and update derive from, and it is covered by tests.
+
+  Existing wrongly-`expired` rows are NOT repaired by this change; a backfill is
+  a separate operation for the leads to run after this ships.
+
+- 245c047: Derive a bulletin board's status from its start date on CREATE, not only on update
+
+  Creating an announcement that starts later the same day published it immediately.
+  Create and update each carried their own copy of the rule and both compared the
+  start date against the end of today rather than against now, so an announcement
+  created at 16:50 to start at 22:00 was written `active` and the Upcoming tab
+  stayed empty. The two cron sweeps compared against now, so all three disagreed.
+
+  The rule is now one function, `deriveBulletinStatus`, shared by create and
+  update and using the same clock as the sweeps. An announcement whose window has
+  already closed is written `expired` rather than published and retracted.
+
+- 516f55d: Read the season pass CSV/Excel expiry cell in the site's time zone
+
+  A spreadsheet cell carries a wall clock and no zone, but every step before the
+  import read it as UTC: `Joi.date().iso()` converted the text before the
+  controller saw it, ExcelJS turns a date-formatted cell into UTC midnight, and
+  `new Date()` on a UTC container did the same. A pass imported as `2026-12-05`
+  came back to a Singapore reader as 8am on the 5th, and `2026-12-05T18:45`
+  rolled over into the 6th.
+
+  `parseExpiryDate` now moves to `src/utils/vehicle-import.util.ts` and reads the
+  cell in `Asia/Singapore` before storing the instant — the same convention
+  `date-format.util.ts`, the patrol logs and the attendance reports already use
+  server-side, and the server-side equivalent of the `v-model:utc` binding the
+  season pass form uses in the browser.
+
+- 60cd128: Default the visitor-invite `type` to `guest` so already-installed resident app builds can invite again.
+
+  `POST /api/visitor-transactions/invite/:inviterId` made `type` a required field when the
+  contractor invite was added. Every resident app build already in the stores sends no `type`, so
+  those users get a 400 — `"type" is required` — on a form that has no Type field. `type` now
+  defaults to `guest`, which is exactly what the endpoint did before the contractor work.
+  Contractor invites are unchanged: `contractorType` is still required when `type` is `contractor`,
+  and an unrecognised `type` is still refused.
+
+## 3.52.3
+
+### Patch Changes
+
+- 57365e1: 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.
+
+- 3b4d5c9: `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.
+
+- b1400ac: 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.
+
 ## 3.52.2
 
 ### Patch Changes

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@7365admin1/core",
   "license": "MIT",
-  "version": "3.52.3-staging.248",
+  "version": "3.52.4",
   "author": "7365admin1",
   "main": "dist/index.js",
   "module": "dist/index.mjs",

package/.changeset/bulletin-board-create-rollback.md

@@ -1,16 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Stop silently discarding a bulletin whose recipients include a service app with no users.
-
-`POST /api/bulletin-boards` inserts the announcement inside a Mongo transaction and then
-notifies each recipient group. The five per-service-app blocks each carried a bare `return;` for
-"this site has no id" and "this app has no registered users". Those returns left the enclosing
-`try` before `commitTransaction()`, so the session was ended with the transaction still open and
-the announcement was rolled back — while the controller still answered `201 Created`. Selecting
-Cleaning, M&E, Pest Control, Landscaping or Pool Maintenance at an estate with no users of that
-app therefore made the announcement vanish with no error anywhere.
-
-The five blocks are now one loop over a recipient-to-app-slug map, and a missing push audience
-skips one notification instead of ending the request. Same apps, same order, same payloads.

package/.changeset/bulletin-expiry-sweep-skips-deleted.md

@@ -1,23 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Stop the bulletin-board expiry sweep from overwriting deleted announcements
-
-`processExpiredBulletinBoards` runs hourly and matched on the dates alone:
-`{ noExpiration: false, endDate: { $lt: now } }`. A soft delete only rewrites
-`status` and `deletedAt` - the row keeps its start and end dates - so every
-deleted announcement whose end date had passed matched the sweep, and its
-`status: "deleted"` was overwritten with `status: "expired"`. The announcement
-then reappeared on the Expired tab, and the user who deleted it saw it come
-back.
-
-Measured read-only on staging: of 63 rows carrying a real `deletedAt`, only 33
-still read `deleted` - 30 (48%) had been flipped to `expired` by the sweep.
-
-The query now excludes `status: "deleted"`. It lives in the model next to
-`deriveBulletinStatus` as `expiredBulletinSweepFilter`, so the rule the sweep
-uses is the same one create and update derive from, and it is covered by tests.
-
-Existing wrongly-`expired` rows are NOT repaired by this change; a backfill is
-a separate operation for the leads to run after this ships.

package/.changeset/bulletin-status-derivation.md

@@ -1,15 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Derive a bulletin board's status from its start date on CREATE, not only on update
-
-Creating an announcement that starts later the same day published it immediately.
-Create and update each carried their own copy of the rule and both compared the
-start date against the end of today rather than against now, so an announcement
-created at 16:50 to start at 22:00 was written `active` and the Upcoming tab
-stayed empty. The two cron sweeps compared against now, so all three disagreed.
-
-The rule is now one function, `deriveBulletinStatus`, shared by create and
-update and using the same clock as the sweeps. An announcement whose window has
-already closed is written `expired` rather than published and retracted.

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

@@ -1,11 +0,0 @@
----
-"@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/csv-import-expiry-timezone.md

@@ -1,18 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Read the season pass CSV/Excel expiry cell in the site's time zone
-
-A spreadsheet cell carries a wall clock and no zone, but every step before the
-import read it as UTC: `Joi.date().iso()` converted the text before the
-controller saw it, ExcelJS turns a date-formatted cell into UTC midnight, and
-`new Date()` on a UTC container did the same. A pass imported as `2026-12-05`
-came back to a Singapore reader as 8am on the 5th, and `2026-12-05T18:45`
-rolled over into the 6th.
-
-`parseExpiryDate` now moves to `src/utils/vehicle-import.util.ts` and reads the
-cell in `Asia/Singapore` before storing the instant — the same convention
-`date-format.util.ts`, the patrol logs and the attendance reports already use
-server-side, and the server-side equivalent of the `v-model:utc` binding the
-season pass form uses in the browser.

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

@@ -1,9 +0,0 @@
----
-"@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

@@ -1,16 +0,0 @@
----
-"@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/.changeset/visitor-invite-type-default.md

@@ -1,12 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Default the visitor-invite `type` to `guest` so already-installed resident app builds can invite again.
-
-`POST /api/visitor-transactions/invite/:inviterId` made `type` a required field when the
-contractor invite was added. Every resident app build already in the stores sends no `type`, so
-those users get a 400 — `"type" is required` — on a form that has no Type field. `type` now
-defaults to `guest`, which is exactly what the endpoint did before the contractor work.
-Contractor invites are unchanged: `contractorType` is still required when `type` is `contractor`,
-and an unrecognised `type` is still refused.