@7365admin1/core 3.51.1-staging.229 → 3.52.0

package/CHANGELOG.md

@@ -1,5 +1,78 @@
 # @iservice365/core
 
+## 3.52.0
+
+### Minor Changes
+
+- bd4bd88: Add a bulk camera import on the existing guided path.
+
+  `POST /api/site-cameras/bulk` accepts a site and up to 200 rows from the
+  technician survey sheet, derives each camera's relay address from its recorder
+  and channel number, and returns a per-row result. `commit: false` previews and
+  writes nothing; `commit: true` writes the rows that passed. Rows that are ANPR,
+  that carry a hand-written address, or whose channel is outside 1-256 are refused
+  by name, and a camera already at the site is reported as a duplicate rather than
+  as a write error. Creates `type: "ip"` cameras only and needs the same write
+  gate as the single-camera form.
+
+### Patch Changes
+
+- 5af369c: Record who added, changed or removed a camera.
+
+  "Who changed this camera's address, and when" had no answer anywhere in the system: a camera record
+  carries `createdAt`/`updatedAt` and no actor, and a write overwrites the previous `host` in place. At
+  Seventh Condominium that turned a one-line port correction into nine days.
+
+  `add`, `updateById` and `deleteById` on site cameras now append a row to the existing append-only
+  `console-audit` collection, with the actor from the session, the camera id, and `before`/`after`
+  values drawn from a per-action allow-list. No schema changes, no migration, and no new collection.
+
+  The allow-list is the boundary that matters: a camera document holds a device credential, and
+  `username` and `password` are not on it. `loadForWrite` still never reads them.
+
+- 16a9105: Decouple the camera health sweep from the wall's tile ceiling.
+
+  `getSiteHealth` sliced its input to `maxTiles` (9), so a health request covering a 150-camera site
+  answered for the first nine cameras and said nothing at all about the other 141 — and did not report
+  that it had shortened the list. No client could build a site-wide "which of my cameras is down" view,
+  however it asked.
+
+  Health is now bounded by its own `maxHealthCameras` (`CAMERA_HEALTH_MAX_CAMERAS`, default 200), and a
+  request past that cap comes back with `requested` / `returned` / `truncated` instead of a quietly
+  partial list. The device fan-out is unchanged: `maxConcurrentProbes` still bounds probes in flight at
+  4, the reachability probe is still cached per recorder, and `probeCamera` still reads a cached device
+  probe rather than making a fresh one — so a 150-camera sweep costs a recorder no more than a 9-camera
+  one after the first pass.
+
+- 398b374: HID Amico: stop silently deriving the credential encryption key from
+  ACCESS_TOKEN_SECRET. Reading still accepts the legacy key so existing credentials
+  keep working (and now logs an error saying so), but writing a new credential
+  refuses with a message naming HID_AMICO_SECRET, so a later rotation of the JWT
+  signing secret cannot orphan credentials that were written after this.
+- 8113e31: HID face registration: never retain the captured photo. Identity `metadata` is stripped of
+  `photo` and of any inline `data:image/...` value on every write, and reader notification
+  payloads (`user_image`, `access_photo`) are redacted of image data before they are persisted
+  as audit events. Enrollment state (`facialEnrolled`, `facialEnrolledAt`, `facialData`,
+  `imageTimestamp`) is unchanged.
+- b097964: Constrain a site camera's `direction` to a fixed set instead of accepting any string.
+
+  `Joi.string().allow("entry", "exit", "both", "none")` reads like a whitelist but is not one — on a
+  validator that already accepts every non-empty string, `.allow()` only adds permitted values, so the
+  field rejected nothing. It is now `.valid()`.
+
+  The accepted set is `entry | exit | both | none | visitors | residents`: the four values the staging
+  collection actually holds (measured read-only across all 22 rows), plus the two extra options
+  layer-common's live `CameraForm.vue` offers for ANPR cameras. No stored camera and no reachable form
+  is refused. Whether `visitors` and `residents` are directions at all is a product question; dropping
+  them later is a zero-row migration.
+
+- Visitor list: decide the Guests tab by "every requested status is pre-arrival"
+  instead of matching one specific status set, so the tab keeps filtering on the
+  expected arrival date for both the approved+pending request sent by
+  layer-common `main` and the approved+pending+rejected request sent by
+  layer-common `staging` (DV-0080). Extracted as `isPreCheckInStatusOnly` with
+  tests pinning each case.
+
 ## 3.51.0
 
 ### Minor Changes

package/package.json

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

package/.changeset/camera-edit-audit-trail.md

@@ -1,16 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Record who added, changed or removed a camera.
-
-"Who changed this camera's address, and when" had no answer anywhere in the system: a camera record
-carries `createdAt`/`updatedAt` and no actor, and a write overwrites the previous `host` in place. At
-Seventh Condominium that turned a one-line port correction into nine days.
-
-`add`, `updateById` and `deleteById` on site cameras now append a row to the existing append-only
-`console-audit` collection, with the actor from the session, the camera id, and `before`/`after`
-values drawn from a per-action allow-list. No schema changes, no migration, and no new collection.
-
-The allow-list is the boundary that matters: a camera document holds a device credential, and
-`username` and `password` are not on it. `loadForWrite` still never reads them.

package/.changeset/camera-health-decouple-from-wall-cap.md

@@ -1,17 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Decouple the camera health sweep from the wall's tile ceiling.
-
-`getSiteHealth` sliced its input to `maxTiles` (9), so a health request covering a 150-camera site
-answered for the first nine cameras and said nothing at all about the other 141 — and did not report
-that it had shortened the list. No client could build a site-wide "which of my cameras is down" view,
-however it asked.
-
-Health is now bounded by its own `maxHealthCameras` (`CAMERA_HEALTH_MAX_CAMERAS`, default 200), and a
-request past that cap comes back with `requested` / `returned` / `truncated` instead of a quietly
-partial list. The device fan-out is unchanged: `maxConcurrentProbes` still bounds probes in flight at
-4, the reachability probe is still cached per recorder, and `probeCamera` still reads a cached device
-probe rather than making a fresh one — so a 150-camera sweep costs a recorder no more than a 9-camera
-one after the first pass.

package/.changeset/hid-amico-secret-loud.md

@@ -1,9 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-HID Amico: stop silently deriving the credential encryption key from
-ACCESS_TOKEN_SECRET. Reading still accepts the legacy key so existing credentials
-keep working (and now logs an error saying so), but writing a new credential
-refuses with a message naming HID_AMICO_SECRET, so a later rotation of the JWT
-signing secret cannot orphan credentials that were written after this.

package/.changeset/hid-face-photo-retention.md

@@ -1,9 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-HID face registration: never retain the captured photo. Identity `metadata` is stripped of
-`photo` and of any inline `data:image/...` value on every write, and reader notification
-payloads (`user_image`, `access_photo`) are redacted of image data before they are persisted
-as audit events. Enrollment state (`facialEnrolled`, `facialEnrolledAt`, `facialData`,
-`imageTimestamp`) is unchanged.

package/.changeset/site-camera-bulk-import.md

@@ -1,14 +0,0 @@
----
-"@7365admin1/core": minor
----
-
-Add a bulk camera import on the existing guided path.
-
-`POST /api/site-cameras/bulk` accepts a site and up to 200 rows from the
-technician survey sheet, derives each camera's relay address from its recorder
-and channel number, and returns a per-row result. `commit: false` previews and
-writes nothing; `commit: true` writes the rows that passed. Rows that are ANPR,
-that carry a hand-written address, or whose channel is outside 1-256 are refused
-by name, and a camera already at the site is reported as a duplicate rather than
-as a write error. Creates `type: "ip"` cameras only and needs the same write
-gate as the single-camera form.

package/.changeset/site-camera-direction-valid.md

@@ -1,15 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Constrain a site camera's `direction` to a fixed set instead of accepting any string.
-
-`Joi.string().allow("entry", "exit", "both", "none")` reads like a whitelist but is not one — on a
-validator that already accepts every non-empty string, `.allow()` only adds permitted values, so the
-field rejected nothing. It is now `.valid()`.
-
-The accepted set is `entry | exit | both | none | visitors | residents`: the four values the staging
-collection actually holds (measured read-only across all 22 rows), plus the two extra options
-layer-common's live `CameraForm.vue` offers for ANPR cameras. No stored camera and no reachable form
-is refused. Whether `visitors` and `residents` are directions at all is a product question; dropping
-them later is a zero-row migration.

package/.changeset/visitor-guest-status-filter.md

@@ -1,10 +0,0 @@
----
-"@7365admin1/core": patch
----
-
-Visitor list: decide the Guests tab by "every requested status is pre-arrival"
-instead of matching one specific status set, so the tab keeps filtering on the
-expected arrival date for both the approved+pending request sent by
-layer-common `main` and the approved+pending+rejected request sent by
-layer-common `staging` (DV-0080). Extracted as `isPreCheckInStatusOnly` with
-tests pinning each case.