@7365admin1/core 3.79.1-staging.337 → 3.79.1-staging.339

package/.changeset/cleaning-robot-cloud-connector.md

@@ -0,0 +1,39 @@
+---
+"@7365admin1/core": minor
+---
+
+Cleaning robot: robot cloud connector, and stop projecting robot credentials
+
+Adds the signed client for the cleaning-robot cloud (`robot-cloud.util.ts`,
+`robot-cloud.service.ts`): request signing, the status vocabulary, the
+pixel/metre transform and the area colour conversions, plus the nine
+request/response endpoints. Credentials are passed in by the caller and are
+never read from the environment, logged, or placed in a request body.
+
+Also fixes a credential disclosure in the existing robot listing: `getRobots`
+projected `appKey` and `appToken` — the pair that signs every command sent to
+that estate's robots — into the response, so anyone holding `see-all-robots`
+received them. They are no longer returned.
+
+Fixes `POST /robots`, which had never worked: the service assigned an ObjectId
+where the model's schema wanted a string, so every create ended in
+`400 "createdBy" must be a string` and no robot could be registered at all.
+
+Adds the server-side enforcement of the five robot permissions, which have
+existed in the client catalogue but were never checked by the API. `"*"` allows
+everything; an empty list allows everything only on a `type: "admin"` role (the
+Seven365 staff role is seeded with `[]`, so enforcing it would refuse the
+platform owner); a non-empty list is enforced exactly.
+
+Adds `robotSn` to the robot record (optional, discovered from `get-robot-list`
+when absent) and `robot-fleet.service.ts`, which bridges a stored robot to the
+vendor cloud: live state, maps, map image URLs minted at use, and dispatch.
+
+Adds a table of which application may set up and monitor which robot type, so
+cleaning robots and security robots share one module while each app sees only
+its own.
+
+Adds an optional `type` ("cleaning" | "security") to the robot record with an
+optional filter, so both device classes share one module and one collection
+while each app lists only its own. Existing rows are untouched and an
+unfiltered query behaves exactly as before.

package/CHANGELOG.md

@@ -1,5 +1,64 @@
 # @iservice365/core
 
+## 3.80.0
+
+### Minor Changes
+
+- a267a47: Vehicle statuses say which list a vehicle is on, a site holds a plate once
+  whatever its status, and every vehicle keeps a history.
+
+  **Statuses.** A whitelist vehicle is `active`, a season pass `temporary`, a
+  blocked vehicle `blocked`. Blocking a resident or season pass puts its plate on
+  the blocklist of every active camera except Exit for ten years (whatever the
+  pass's own dates) and takes it OFF every camera's allowed list, so no camera
+  holds a plate on both lists; approving a pending blocklist vehicle uses the
+  same ten years, and a new camera is filled the same way. Unblocking sets `unblocked` and takes the plate off every active camera's
+  blocklist by plate number - and off the allowed list too, so an unblocked car
+  is on no list rather than quietly whitelisted again. A blocked, unblocked,
+  deleted or inactive vehicle can be blocked again in place. Everything that
+  writes, syncs, revokes or recognises a plate at the gate now treats `active`,
+  `temporary` and `blocked` as live; the gate still recognises a season pass as a
+  registered resident until its expiry, and an unblocked plate no longer counts
+  as blocked at visitor check-in.
+
+  **Categories and tabs.** A whitelist vehicle is filed `resident`, a season
+  pass `season_pass` (new), and a vehicle added to the blocklist `visitor` or
+  `contractor` (new in the vehicle enum; default `visitor`); blocked from a visitor transaction it keeps that type - `delivery`, `pick-up` or `drop-off` (new), a guest as `visitor`. A season pass seen at the gate is logged as a `resident` transaction. Blocking keeps the
+  category, so a blocked resident is still `resident`; editing a season pass type
+  on or off moves a whitelist vehicle between `resident` and `season_pass`. The
+  vehicle list takes `view` - `residents`, `season-passes` or `block-listed` -
+  for the three tabs; older season passes saved as `resident` show under Season
+  Passes. The gate counts `resident` and `season_pass` as registered.
+
+  **Update an existing plate from the add form.** `existingPlatesAtSite`
+  answers which of the plates being added the site already holds, with each
+  record's tab and status; `moveVehicle` saves the form's details on that record
+  and moves it to the form's tab (off every camera list, onto the list of its new
+  kind; pending for a security agency without the approve permission). Its
+  history records "moved".
+
+  **Sync.** `syncVehicleToCameras` puts a live vehicle's plate on every active
+  camera of its list that lacks it (a plate saved while its cameras were
+  inactive), camera by camera, and records the cameras that took it;
+  `activeCameraCounts` gives the active cameras per list so the screens can offer
+  it.
+
+  **One plate per site.** Adding a plate the site already has - deleted,
+  pending, temporary, blocked or unblocked included - is refused with its status
+  and "edit the existing vehicle instead" (restore, for a deleted one). The same
+  check guards approve, restore and plate edits. Matching ignores case and
+  spacing.
+
+  **History.** `history` holds the last 20 changes - created, updated,
+  approved, restored, blocked, unblocked, deleted - each with the user's id, the
+  time and the fields that changed. `getSpecificVehicleById` adds each user's
+  name.
+
+  **Also:** the vehicle list returns every status unless one is asked for; the
+  camera's record id (`recNo`) is no longer stored; `processDeletingExpiredVehicles`
+  is no longer needed (the camera enforces each pass's own expiry) and should be
+  unscheduled by the API.
+
 ## 3.79.0
 
 ### Minor Changes