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

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