@7365admin1/layer-common 3.2.8-staging.210 → 3.3.1

package/CHANGELOG.md

@@ -1,5 +1,554 @@
 # @iservice365/layer-common
 
+## 3.3.1
+
+### Patch Changes
+
+- b92f73f: Remove a duplicate `:site` attribute on `HidReaderManagement.vue`.
+
+  `HidReaderForm` was given `:site` twice - `props.site` and then a bare `site`, which is
+  not a name that exists in that component's scope. Vite's Vue plugin treats a duplicate
+  attribute as a compile error, so every consuming application's `nuxt build` failed on
+  this file. The layer's own playground build does not import the component, which is why
+  it was not caught at publish time.
+
+## 3.3.0
+
+### Minor Changes
+
+- 078521d: Add a dedicated HID Cards module with PACS and CSN assignment, card enrollment
+  at an Amico reader, removal, and device-backed card status. HID Users keeps the
+  same card action, and the Card identification toggle now updates the reader
+  configuration as well as site metadata.
+- f368275: Add reader capability and mode configuration, site-linked HID identities,
+  reader-profile physical card handling, and device-backed pagination for HID
+  users and access logs.
+- 330e103: Draw icons with the redesign's Material Symbols Outlined font instead of Material Design Icons.
+
+  Call sites are unchanged - a component still asks for `mdi-close`. The Vuetify icon set
+  translates 233 names (the 204 used here plus Vuetify's own internal aliases) into the
+  Material Symbols ligature; anything unmapped still renders through Iconify as before, so no
+  icon can come out as a blank box. Every consuming application picks this up with no change
+  of its own.
+
+  Also in this release:
+
+  - `TableWithButton`, `ScheduleTaskAreaUpdateMoreAction` and `ScheduleTaskAreaFormDialog` are
+    **removed** - no repository in the organisation referenced them.
+  - The published tarball now carries only what a consumer loads (`files`), not the changesets,
+    CI workflows, tests and render harness.
+  - The check-out label in `VisitorsReportPreview` asked for a `--error` token that does not
+    exist and inherited its colour; it now uses `--err`.
+
+- bb18a57: Make the Pending tab's invitation actions reachable, and say which state an invitation is really in
+
+  The row menu in the service-provider list was drawn only for provider rows, so a
+  pending invitation offered no actions at all — including the cancel that was
+  already wired up behind it. Invitation rows now carry Cancel, Resend and Delete,
+  each behind a confirmation that names the company and the site, and Resend is
+  disabled with the reason while Seven365 has not approved the invitation yet.
+
+  Every invitation also used to read "Pending" whatever had happened to it. Rows
+  now show the state they are actually in — Waiting for Seven365, Waiting for the
+  provider, Not approved, Declined, Cancelled, Expired — in those words, with
+  Seven365's reason shown underneath a rejected one.
+
+  Also here: a new ServiceProviderInvitationPrompt, which is how an existing
+  provider answers an invitation from inside the app they already use, with no
+  sign-up and no one-time code.
+
+  Three contrast fixes found while rendering these screens: the list's tab strip
+  was a hardcoded light grey that turned into a white slab in dark mode and took
+  the tab labels with it; the service type column read the raw stored slug
+  ("security_agency") instead of "Security"; and `on-warning`, `on-info` and
+  dark's `on-error` are now set explicitly, because Vuetify derives white for them
+  and that measures 2.37:1, 3.12:1 and 3.60:1 on those fills — every filled
+  warning, info and error chip, alert and button in the product.
+
+### Patch Changes
+
+- 4ee5fb9: Fix the attach-file icon rendering too faint in `FileInputWithList.vue`.
+
+  The `mdi-paperclip` prepend icon was drawing at Vuetify's default
+  `.v-input__prepend > .v-icon { opacity: var(--v-medium-emphasis-opacity) }`
+  (0.64) - the same field-icon dimming roughly 200 other call sites across this
+  package intentionally rely on (see `utils/theme.ts`), so this is fixed only
+  inside `FileInputWithList.vue`, not in the shared token.
+
+  The icon now renders at full opacity in `--text2`, the same colour
+  `.screen-icon-btn` already uses, so it reads at the same weight as a sibling
+  icon drawn outside a Vuetify field (which was never subject to this opacity
+  rule in the first place). No other icon in this component sits inside
+  `.v-input__prepend`/`.v-input__append`, so nothing else here was affected.
+
+- 84d6a1f: Top bar breadcrumb: name the page, not the folder in front of the context
+  parameter. Every screen of the organization application read "Org", because the
+  route name alone cannot tell that `org` in `/org/:organization/...` is a folder
+  and not a parameter. The rule moves to `utils/breadcrumb.ts` with unit tests
+  covering each application's route shapes; the site applications are unchanged.
+- dd0849e: Draw the camera wall from the gated wall endpoint, and show the server's own
+  reason on a tile.
+
+  `CameraWall` fetched its cameras from `GET /api/site-cameras` - the Settings
+  panel's paginated CRUD list, which took its site from an optional query
+  parameter and checked nothing about the caller. Any signed-in user from any
+  organisation could read every camera in the estate through it, `host` and
+  `username` included.
+
+  It now calls `GET /api/site-cameras/site/:siteId/wall`, which already exists,
+  which the React Native monitoring app was built against, and which is
+  authorised server-side: the caller must be a member of the site, of its owning
+  organisation, or work for an organisation actively engaged to serve it. That
+  endpoint also returns `type: "ip"` cameras only and each camera's capability
+  descriptor, so a wall cannot be handed an ANPR unit and a tile can explain
+  itself.
+
+  Two consequences worth stating:
+
+  - **The pager is gone.** The wall endpoint returns the site's cameras in one
+    answer. Paging a video wall was an artefact of borrowing the CRUD list.
+  - **A tile now prefers the server's `unavailableReason`** over the reason it
+    used to work out itself. The server knows things the browser cannot - chiefly
+    "No recorder is configured for this camera's relay", which is the true answer
+    for every camera in the estate until the API host is configured, and which the
+    wall used to replace with its own guess. Offline still beats everything, since
+    it explains every tile at once.
+
+  No permission gate was invented here. Each application still gates its own menu
+  entry; this component draws what it is given, and the server decides.
+
+  Two smaller things in the same area:
+
+  - **A refused wall now says so.** The catch-all message told every failure to
+    "check your connection", which sends somebody who simply may not see that
+    site off to debug their wifi. A 401/403/404 now reads "You do not have access
+    to this site's cameras." The server answers "not yours" and "does not exist"
+    identically, so this wording does not distinguish them either.
+  - **`middleware/member.ts` is removed.** It read a cookie into an unused
+    variable and did nothing else - a file named like a membership gate that was
+    not one. No page in any of the eleven web apps referenced it. The real check
+    is `plugins/secure-member.client.ts`, driven by `memberOnly` page meta, which
+    is untouched.
+
+- f3fb808: Rewrite the camera wall's detail panel for the people who read it, and stop
+  repeating the same sentence four times.
+
+  The panel under the tiles was written for a developer. On the live wall it
+  read:
+
+  > BBQ AREA
+  > The video page loaded, but this browser cannot confirm a picture is arriving.
+  > The player belongs to the video service and a browser cannot look inside it.
+  > Judge the tile by what you can see, and report a blank or frozen picture.
+  > ● Recorder responding Last picture this server received: none yet
+  > Firmware and device clock are not available: this recorder is reachable over
+  > video only.
+
+  Every one of those statements is true, and the screen was still wrong: it
+  explained cross-origin isolation to a guard, repeated the camera's name the
+  tile already showed, put a green light beside the words "none yet", and printed
+  the same reason on four capability cards in a row.
+
+  Changes, all copy and layout — **no behaviour, no capability gating and no
+  permission check is touched**:
+
+  - **The badge reads "Not confirmed"**, not "Not verified". "Not verified"
+    describes a check we failed to make; "Not confirmed" describes the picture,
+    which is the thing the reader cares about. Same claim, and the wall still
+    refuses to say "Live" until the video service reports a decoded frame.
+  - **The sentence behind it is now an instruction**: "This page cannot confirm
+    the picture is arriving, so check the tile yourself. If it is blank or frozen,
+    report the camera." Why the software cannot confirm it is our problem, and it
+    has been removed from the product.
+  - **The camera's name is no longer a heading of its own.** It is the subject of
+    the status line — "BBQ AREA · Recorder responding" — so a reader on a 3x3 wall
+    still knows which tile the panel describes, without a second caption under the
+    first one.
+  - **"Last picture" is drawn only when there has been one.** A green "Recorder
+    responding" beside "none yet" read as a contradiction. They were never in
+    conflict, but a screen that has to be explained is wrong. The tile's own
+    health line has always behaved this way; the panel now matches it.
+  - **The firmware-and-device-clock sentence is gone**, from the panel and from
+    the tile's tooltip. This screen never showed either value, so explaining their
+    absence gave the reader nothing to do. The server still sends
+    `detailUnavailableReason`; nothing draws it.
+  - **One reason for the group instead of four copies.** When every switched-off
+    control is off for the same reason, that reason and its next step are stated
+    once above the row and each card keeps only its title and its state. When the
+    reasons differ — "the recorder is unreachable" and "this camera cannot move"
+    are two problems with two different people to ask — the group note is refused
+    and each card carries its own again. New rule 7, in `camera-wall.ts`, with
+    four tests.
+  - Shorter next-step and no-signal wording, and a subject on the recorder's
+    status labels ("Recorder not checked yet" rather than "Health not checked
+    yet").
+
+  Rules 3 and 6 are intact: the server's own sentence is still shown verbatim and
+  never rewritten, and the recorder's state is still a separate fact from the
+  tile's badge.
+
+- e177e9e: Mark the selected camera on the wall, and stop telling the reader to raise a
+  ticket without saying what for.
+
+  Two things the owner found on the live wall after the last copy pass. Both are
+  copy and presentation only — **no behaviour, no capability gating, no permission
+  check and no request is changed.**
+
+  **1. The camera's name was still printed twice.**
+
+  The tile said `BBQ AREA` and the panel underneath said it again. The last pass
+  merged the panel's heading into its status line, which changed the layout and
+  left the repetition exactly where it was.
+
+  The name was there to answer "which of these nine tiles is this panel about?".
+  That is a real question and a name is the wrong answer to it — it makes the
+  reader scan the wall for a matching caption. So:
+
+  - **the selected tile is now visibly selected**: a 3 px accent ring with a scrim
+    hairline inside it, so the ring holds against a bright picture as well as a
+    dark one, plus the accent underline on the name chip that the toolbar already
+    uses to mark a selected tool. Both read at 1x1, 2x2 and 3x3;
+  - **the camera's name is removed from the panel entirely**. The panel opens on
+    the recorder's state — "● Recorder responding";
+  - `aria-current` marks the same tile for anyone not looking at the ring.
+
+  The highlight had never worked in the most common case, which is why the name
+  was load-bearing: it was bound to the raw clicked id, and before anyone clicks —
+  or after paging — nothing on the wall was marked while the panel was already
+  describing the first tile. It is now bound to the tile the panel actually
+  resolves to, so the two can never disagree.
+
+  **The panel can never be about a tile that is off screen**, so it never needs to
+  name one: the focused camera is resolved out of the current PAGE, so paging away
+  from a selection re-resolves to the first tile of the page in front of you and
+  the ring follows. Paging back restores the original selection. Extracted as
+  `focusedCamera()` in `camera-wall.ts` with four tests, including the 5-cameras
+  -across-2-pages case.
+
+  **2. "Ask your Seven365 administrator" was a dead end.**
+
+  It was the whole of the advice under every switched-off control, and it tells
+  the administrator nothing and a property manager only to go and wait. The screen
+  never said what the request should ask for.
+
+  The advice now names the two changes that are actually missing, because they are
+  two different jobs for two different people: **the site's network has to let our
+  server reach the camera recorder**, and **that recorder then has to be added to
+  the server's configuration**. Both are stated in plain words, with who arranges
+  them, and with the fact that neither is switchable from this page.
+
+  No environment variable name appears in any of it — those belong in
+  `iservice365-core/docs/camera-integration-config.md`, not on a property
+  manager's screen — and there is a test that keeps it that way. The other reason
+  codes (`device-http-disabled`, `device-http-unreachable`, `device-http-locked-out`,
+  `control-not-enabled`, `no-recorder-configured`, and the unknown-code fallback)
+  get the same treatment; the Site Settings ones already said what to do and are
+  unchanged.
+
+  The truthful-status rules are untouched: the wall still refuses to say "Live"
+  until the video service reports a decoded frame, and the recorder's state is
+  still a separate fact from the tile's badge.
+
+- cf29add: Show each client's nature of business on the super-admin Client List, so the
+  one screen says who a client is, what kind of business they are, how many sites
+  they have and where their subscription stands.
+
+  The Client List and the admin app's Organizations list are the same screen for
+  the same job, and the Client List is the one that stays. Organizations showed
+  one thing the Client List did not: the organisation's **nature** — Property
+  Management Agency, Security Agency, Cleaning Services, and so on. That is what
+  a client actually _is_, and the list had no way to say it.
+
+  The value was already arriving. `GET /api/organizations/v2/orgs/subscriptions`
+  has always projected `nature`; the screen simply never read it. So this is one
+  column, no backend change, printed with the same `formatNature` helper the
+  Organizations list uses, so both screens say a nature the same way while both
+  exist.
+
+  Two changes pay for the width, because the table was already 1389px in a
+  1386px viewport and a new column would have pushed it to 1405px:
+
+  - **The email moved under the organisation name.** It identifies the same
+    client the name does and had a full column to itself.
+  - **The Status column is gone.** The table is fetched with the status the
+    chosen tab asks for, so on the Active tab every row said "active" and on
+    Suspended every row said "suspended" — a column that could only ever repeat
+    the tab the reader was standing on. The status is still on the screen: it is
+    the tab, and the row menu offers Suspend or Activate accordingly.
+
+  Measured after the change: **1332px at a 1386px viewport and 1386px at 1440px,
+  with no horizontal overflow at either** — the first time this table has fitted
+  its own page.
+
+  A client whose record carries no nature reads "Not recorded" rather than
+  leaving a blank cell. `nature` is a required enum on the organisation model, so
+  that is defensive cover for older records, not an expected state.
+
+  No filter was added for it. The list's `$match` has no `nature` term, so the
+  only filter that could be built here would filter the ten rows on screen and
+  silently ignore the rest — the same kind of control that was removed from this
+  screen for pretending to work. A real one needs the aggregation to accept
+  `nature` first.
+
+- e100fc9: Make the super-admin Client List say what a client's subscription actually is,
+  instead of printing "-".
+
+  `ClientMain.vue` showed a dash in Plan Type, Billing Cycle, Subscription Start
+  and Subscription End for every client with no subscription document - which is
+  most of them. Four dashes read as a broken screen. It is one ordinary state:
+  nobody has set that client up yet.
+
+  `utils/client-subscription.ts` derives the state from the row the endpoint
+  actually returns and never claims more than the record proves:
+
+  | Record says                    | Screen says                 |
+  | ------------------------------ | --------------------------- |
+  | no subscription document       | No subscription set up      |
+  | running                        | Active                      |
+  | `billingMode: "paid"`          | Active (paying)             |
+  | `billingMode: "complimentary"` | Complimentary (not charged) |
+  | `status: "suspended"`          | Suspended                   |
+  | `status` ended / canceled      | Ended                       |
+  | end date already passed        | Ended (needs attention)     |
+
+  Nothing sends a charging arrangement today, so a live record reads as plain
+  "Active" - not "paying", because nothing in the data proves that.
+
+  Removed as dead or misleading:
+
+  - The "Filter by plan type" dropdown. It was fed organization _nature_ values
+    (`security_agency`, `cleaning_services`, ...) and sent as `type`, which the
+    aggregation applies to `subscription.type` - whose only legal values are
+    `organization` and `affiliate`. Every option but "All" returned zero rows.
+  - `planTypeLabel`'s `sub.paidType` branch (the field exists in no repo) and its
+    `sub.description` branch (not in the endpoint's projection).
+  - `getSubscriptionByOrgId`, destructured and never called.
+
+  `ClientDetailForm.vue`'s Subscription Information section was six dropdowns and
+  two date boxes that looked editable and saved nothing - the plan list was two
+  invented names, and Start/End were always blank because nothing ever loaded
+  them. It now shows the same derived values as the list, read-only. The write
+  path is unchanged: Submit still saves the organisation name and contact.
+
+  Two smaller display fixes on the list: the two date column headers are "Start
+  Date" and "End Date" rather than "Subscription Start"/"Subscription End", and
+  the Sites badge is the count rather than "3 Sites" under a "Sites" header
+  (which also used to read "1 Sites"). Both were needed to keep the Actions
+  column on screen at 1440px.
+
+- c256755: Let a Seven365 staff member actually set up and edit a client's subscription
+  from the super-admin Client List.
+
+  Phase 1 made that list tell the truth: a client nobody had set up read "No
+  subscription set up" instead of four dashes. There was still nothing anywhere
+  that could set one up. The API endpoints now exist
+  (`POST`/`PUT`/`GET /api/subscriptions/console/:id`, staff-only, `:id` being the
+  client's organisation), so this is the screen in front of them.
+
+  **What a person can now do**
+
+  - From a row that has no subscription: **Set up subscription**, straight off
+    the row.
+  - From the row menu, or from the client's own drawer: **Edit subscription** -
+    plan, start date, end date, and whether the client is complimentary or
+    paying.
+  - The list re-reads itself after a save, so the row shows the new state
+    immediately, using the same Phase 1 derivation (`utils/client-subscription.ts`).
+
+  **Four questions, and nothing else asked**
+
+  Plan, charging (complimentary or paying), start date, end date. Everything
+  else is worked out: a plan is priced per site, per month, so the form shows the
+  per-site price, this client's live site count and the monthly value that comes
+  out of the two - already multiplied, with "not charged - complimentary" beside
+  it when the client is free. A client with no sites yet is 0 and is said so
+  plainly rather than refused.
+
+  **Complimentary is the default**, because every client today is complimentary.
+  It is a real arrangement with real dates Seven365 monitors, not an absence of
+  one, and it is exactly as quick to set as a paying subscription.
+
+  **Refused in the form, before the request goes out** - in the API's own words,
+  so the two can never disagree: no plan chosen; a plan that does not exist or is
+  no longer active (named); no end date ("Every client has one, free or not."); an
+  end date on or before the start date; an unreadable date; a complimentary
+  subscription carrying a price. When the server refuses anyway, its message is
+  what the screen shows.
+
+  **Deliberately not here:** no card field, no payment step, no gateway - Red Dot
+  takes payment, and none of it belongs on a staff screen. No suspend and no
+  reactivate: that is Phase 3, and the API's edit endpoint does not accept a
+  status, so there is no control here that could set one. The drawer's
+  Subscription Information stays read-only; the button beside it opens this form.
+
+  `useSubscription` gains `getConsoleSubscriptionByOrgId`,
+  `setUpConsoleSubscription` and `updateConsoleSubscription`. Nothing existing
+  changed shape.
+
+- 6b008c4: Split the dark theme's `primary` into a foreground colour and a fill, so text
+  using it is readable again.
+
+  Dark `primary` was set to the brand navy `#17506F` so the navigation drawer
+  would read as a surface. That is the right value for a fill — a white label on
+  it measures 8.70:1 — but Vuetify emits `.text-primary` from the same token, so
+  every `class="text-primary"` sentence and every `color="primary"` icon, spinner
+  and text button rendered navy on a dark background:
+
+  |                                                 | before | now        |
+  | ----------------------------------------------- | ------ | ---------- |
+  | `primary` as text on the dark page `#0E1319`    | 2.14:1 | **6.40:1** |
+  | `primary` as text on a dark card `#1B242F`      | 1.80:1 | **5.38:1** |
+  | `primary` as text on `surface-bright` `#26313E` | 1.52:1 | **4.53:1** |
+
+  Dark `primary` is now `#5B9BE0`. That is not a new colour: it is the blue the
+  camera wall already draws its accents in (`--vms-accent`), so the two dark
+  surfaces in this product agree on one blue.
+
+  The navigation drawer no longer depends on `primary`. Both themes gain a
+  `brand-surface` colour — `#042134` light (identical to light `primary`, so
+  light mode renders exactly as before) and `#17506F` dark — and
+  `Layout/NavigationDrawer.vue` is painted with it. Its white label still reads
+  16.51:1 light and 8.70:1 dark. `floating` was dropped from the drawer so it
+  draws its own edge: the fill is 2.14:1 against the dark page, under the 3:1 a
+  boundary wants, and the border at `border-opacity` 0.35 is 3.22:1.
+
+  Where `primary` is still used as a fill, Vuetify derives `on-primary` from it
+  and picks black, which reads at 7.21:1. What a light `primary` cannot carry is
+  a hardcoded white label, and a handful of app-side sites still set one — see
+  the pull request for the list.
+
+  The light theme is unchanged. The colours moved to `utils/theme.ts` and
+  `utils/theme.test.ts` now measures them, so a token cannot be moved for one use
+  and quietly broken for the other again.
+
+- 626d1d7: Dashboard and filled-primary surfaces now follow the theme in dark mode.
+
+  - `DashboardMain` painted its panels, list rows and text with fixed hex values,
+    so the ACTIVE PATROL / STAFF STATUS / Feedbacks cards rendered white on the
+    dark page and the heading and KPI figures were dark grey on near-black
+    (1.19:1). They now use the theme's surface and foreground tokens.
+  - `DARK_THEME` had no `on-primary`, so Vuetify derived white for every filled
+    `primary` button, chip, alert, tab bar and snackbar - 2.91:1. It is now set
+    explicitly and measures 6.40:1.
+
+  The print / PDF / Word export styles are unchanged and stay ink-on-white.
+
+- a39ce7f: Fix four hard-coded route names that do not exist in the apps that render them.
+
+  This layer is extended by apps whose pages sit at different depths, so a route
+  name written literally here is correct in some consumers and unknown in the
+  rest - and `router.push({ name })` on an unknown name throws, taking the click
+  (and, in a nav list, its neighbours) with it. Route names are now resolved
+  against the running app's own router via `utils/route-name.ts`
+  (`pickRouteName`), which returns the first candidate the app actually has, or
+  `null` so the caller can hide the control rather than navigate somewhere wrong.
+
+  - `QrTemplate/PrintDialog.vue` pushed `keys-visitor-pass-add`, which no
+    consumer has; both apps that render this dialog nest the page under
+    `[org]/[site]`. It also sent `site` as a query parameter where the
+    destination reads `org` and `site` as path parameters, so neither was
+    filled. Generating a pass from the print dialog threw.
+  - `ServiceProviderMain.vue` always rendered a Billing button
+    (`showBillingButton` defaults to `true`) pointing at
+    `org-site-service-provider-mgmt-billing`, a page only
+    web-app-property-management has. The button now renders only where the page
+    exists; property-management is unchanged.
+  - `require-customer.vue` used `org-organizations-customers-add`; the org app's
+    page is `pages/org/[organization]/customers/add.vue`, whose name is
+    `org-organization-customers-add` - singular. The only way off that dead-end
+    page threw. Every other app already took the cross-app URL branch and was
+    unaffected.
+  - `WorkOrder/Main.vue` used `work-order-details`, which no consumer has; the
+    detail screen is `org-site-work-orders-id`. No app currently renders this
+    component, so nothing was user-visible.
+
+  `require-organization-membership.vue` was reported alongside these and is NOT
+  changed: `organizations-create` is a real route in web-app-org, and that branch
+  only runs there.
+
+- ae59ec4: Say when the Service Providers list and the Attendance Settings dialog failed to load, instead of showing an empty screen
+
+  Both surfaces treated a failed request as "there is nothing here". The Service Providers table defaulted a bad response to `[]` and drew the standard "No data available" row; the Attendance Settings dialog read its fields off whatever came back and, when that was not an object, simply opened with geofencing off and every field blank. Neither told the operator anything had gone wrong.
+
+  The table now renders the shared `DashboardEmptyState` in its error tone when the last load failed, and the dialog shows an alert saying what is on screen is not what is saved.
+
+- 82d0091: Send the site with HID reader discovery. `HidReaderForm` now receives the site
+  from `HidReaderManagement` (which already has it from the page route) and
+  includes it in the `readers/discover` request, so the endpoint can authorize the
+  caller against that site. The request falls back to the old body once, and only
+  on the unknown-field validation error, so discovery keeps working against an API
+  that has not picked the change up yet.
+- c887977: Add a Notification Settings screen, shared by every web app.
+
+  A person can now choose, per module and per delivery route, what they hear
+  about: in the app, on their phone, or by email. The screen only lists modules
+  their role actually gives them, and a route a module cannot use is shown dimmed
+  with the reason in plain words rather than hidden.
+
+  Modules are collapsed by default with a one-line summary of what is on, so
+  somebody with many modules gets a short list instead of thirty switches. There
+  is a master control for everything and one per module.
+
+  The choices are enforced where notifications are sent, in `@7365admin1/core` and
+  in the API, so a switch here actually stops the message.
+
+- 5089b71: Group the sidebar's sections and give the list screens the design's page
+  scaffold.
+
+  - `withSections()` walked each application's menu in the order it was given and
+    printed a heading whenever the section changed, so Property Management drew
+    SERVICE DESK, PROPERTY and SECURITY OPERATIONS **twice each**. Items are now
+    grouped under one heading per section, in the order the design lists them,
+    with the application's own order kept inside each section. No menu item is
+    added, hidden, renamed, re-routed or re-gated.
+  - `ServiceProviderMain`, `FeedbackMain`, `InvitationMain` and `WorkOrder/Main`
+    had no page title, put their primary action top-left, floated the search
+    outside the card, and stacked the refresh/pager on a bar above the tabs. They
+    now use `PageHeader` / `AppCard` / `CardToolbar` / `AppButton` / `AppField`:
+    a 22px title with the action on the right, then one in-card row with the tabs
+    on the left and search, count and pager on the right.
+  - `SwitchContext` and the rail's application name print in full instead of
+    truncating to "Seventh Cond…" / "Property Managem…".
+  - The security dashboard's `ACTIVE PATROL` / `STAFF STATUS` panel headings are
+    written the way the design writes them, matching their sibling panels.
+
+  Placement and wording only: the same buttons open the same dialogs under the
+  same permissions, the same tabs load the same lists, and the tables, columns,
+  filters and row menus are untouched.
+
+- 8813b26: Work Orders and Feedbacks: say why the list is empty instead of quoting an
+  internal id. A service-provider account viewing a site its company is not linked
+  to got an empty table and the toast "Service provider with siteId
+  68f0...dadada not found" - an internal sentence, naming no action, on a screen
+  that then looked broken. The sidebar offers every site in the organisation, not
+  only the ones the account covers, so this is an ordinary mis-click rather than a
+  fault. `findServiceProviderIdBySite` still refuses (returning null would drop the
+  provider filter and show another provider's work orders) but now refuses with a
+  sentence the reader can act on, and no longer dies with a TypeError when the
+  account carries no provider list at all. Unit tests added in `utils/data.test.ts`.
+  Affects the six service-provider applications that call it: security, hygiene,
+  landscape, mechanical-electrical, pest-control and pool-mgmt.
+- 309d0e3: Fix the duplicate `:headers` binding on `<v-data-table>` in `TableMain.vue`
+  that broke every consuming app's build.
+
+  The merge of `staging` into `feature/DV-0119` kept both sides' `:headers`
+  line: the branch's older `:headers="headers"` and staging's newer
+  `:headers="tableHeaders"`. Vue's template compiler rejects a duplicate
+  attribute outright ("Duplicate attribute."), so any app that compiles this
+  component fails to build. This package's own `yarn build` only builds
+  `.playground`, which never imports `TableMain.vue`, so the fault published
+  as `3.2.8-staging.201` and surfaced only in the eleven web apps.
+
+  `:headers="tableHeaders"` is the correct one and is kept.
+  `tableHeaders` returns `props.headers` unchanged unless a caller has put
+  `weight` on a column, so it is a strict superset of the old binding - no
+  caller behaviour changes, and the weighted-column support added in
+  "Bring the shared table card up to the design's table spec" stays working.
+
+  Also adds `test/sfc-compile.test.mjs`, which compiles every `.vue` template in
+  the package and fails on any template syntax error. It fails on the broken
+  file and passes on the fixed one.
+
 ## 3.2.7
 
 ### Patch Changes

package/components/HidQrCodeConfiguration.vue

@@ -616,7 +616,7 @@ async function openPermissionDialog(category: THidPermissionCategory | "intercom
       page: 1,
       limit: 500,
     });
-    permissionCandidates.value = response.items ?? response.data?.items ?? [];
+    permissionCandidates.value = response.items || [];
     selectedPermissionIds.value = new Set(
       permissionCandidates.value
         .filter((candidate) => category === "intercom" ? candidate.intercom : candidate.selected)

package/components/HidUserEnrollment.vue

@@ -936,7 +936,7 @@ async function loadSubjectCandidates() {
       page: 1,
       limit: 500,
     });
-    permissionCandidates.value = response.items ?? response.data?.items ?? [];
+    permissionCandidates.value = response.items || [];
   } finally {
     loadingSubjects.value = false;
   }

package/composables/useHidAmico.ts

@@ -80,18 +80,11 @@ type HidVisitorQrData = {
 type HidVisitorQrResponse = HidVisitorQrData | { data: HidVisitorQrData };
 
 type HidPermissionListResponse = {
-  items?: THidPermissionCandidate[];
-  page?: number;
-  pages?: number;
-  pageRange?: string;
-  limit?: number;
-  data?: {
-    items?: THidPermissionCandidate[];
-    page?: number;
-    pages?: number;
-    pageRange?: string;
-    limit?: number;
-  };
+  items: THidPermissionCandidate[];
+  page: number;
+  pages: number;
+  pageRange: string;
+  limit: number;
 };
 
 type HidFacialEnrollmentResult = {

package/composables/usePromoCode.ts

@@ -28,66 +28,9 @@ export default function usePromoCode() {
     });
   }
 
-  /** One record, by its id. The console's detail screen opens on this. */
-  function getById(id: string) {
-    return useNuxtApp().$api<Record<string, any>>(
-      `/api/promo-codes/id/${id}`,
-      {
-        method: "GET",
-      }
-    );
-  }
-
-  /**
-   * Edit a code.
-   *
-   * `code` is NOT sent. It is immutable on the server - a subscription records
-   * the promo code it was bought with as text, so renaming one rewrites every
-   * invoice that already quotes it. The API accepts a `code` key and ignores
-   * it; leaving it out of the body means the screen can never look as though
-   * it changed something it did not.
-   */
-  function update(id: string, value: Partial<TPromoCode>) {
-    const { code, ...body } = value as Record<string, any>;
-
-    return useNuxtApp().$api<Record<string, any>>(`/api/promo-codes/${id}`, {
-      method: "PUT",
-      body,
-    });
-  }
-
-  /** Turn a code off, or back on. The only two states staff may set. */
-  function updateStatus(id: string, status: "active" | "disabled") {
-    return useNuxtApp().$api<Record<string, any>>(
-      `/api/promo-codes/${id}/status`,
-      {
-        method: "PATCH",
-        body: { status },
-      }
-    );
-  }
-
-  /**
-   * Remove a code from the console.
-   *
-   * A SOFT delete on the server: the record stays and is marked disabled and
-   * deleted, because subscriptions and invoices quote the code they were
-   * bought with. It leaves the list and stops being redeemable; it is not
-   * erased.
-   */
-  function remove(id: string) {
-    return useNuxtApp().$api<Record<string, any>>(`/api/promo-codes/${id}`, {
-      method: "DELETE",
-    });
-  }
-
   return {
     add,
     getPromoCodes,
     getByCode,
-    getById,
-    update,
-    updateStatus,
-    remove,
   };
 }

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.8-staging.210",
+  "version": "3.3.1",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "//files": "What a consumer extending this layer actually loads. Without this npm ships the whole working tree - the changesets, the CI workflows, the render harness in tools/ and any scratch directory that happened to exist at publish time. Nuxt resolves a layer by directory, so every runtime directory below has to stay listed; adding a new top-level runtime directory means adding it here too.",

package/utils/promo-code-form.test.ts

@@ -1,437 +0,0 @@
-import assert from "node:assert/strict";
-import { test } from "node:test";
-
-import {
-  promoExpiryDate,
-  promoCodeFormValues,
-  promoCodeUpdatePayload,
-  validatePromoCodeEdit,
-  promoCodeApiError,
-} from "./promo-code-form.ts";
-
-/**
- * THE PROMO CODE EDITOR AND THE THREE WRITE CALLS BEHIND IT.
- *
- * Two halves, both pinned here:
- *
- *  1. the rules the edit form applies before it sends anything - taken from
- *     the MERGED backend (`promoCodeUpdateSchema` in `@7365admin1/core`), not
- *     from a guess about it;
- *  2. what `usePromoCode()` actually puts on the wire. The composable is three
- *     `$api` calls, and the thing that can silently be wrong about it is the
- *     verb, the path or the body - a `PUT` to the wrong path, or a body that
- *     carries `code` and so looks as though it renamed a code it cannot.
- *
- * The composable reaches for `useNuxtApp()`, which only exists inside a Nuxt
- * app, so one stub stands in for it and records the call.
- */
-
-const NOW = new Date(2026, 7, 20, 12, 0, 0); // 20 Aug 2026, midday
-
-// ---------------------------------------------------------------------------
-// The expiry rule
-// ---------------------------------------------------------------------------
-
-test("an expiry date is read as the END of its day, in both stored formats", () => {
-  // A code dated today is good for all of today, so a check at midday passes.
-  const usFormat = promoExpiryDate("08/20/2026");
-  assert.ok(usFormat);
-  assert.equal(usFormat!.getHours(), 23);
-  assert.ok(usFormat!.getTime() > NOW.getTime());
-
-  const iso = promoExpiryDate("2026-08-20");
-  assert.ok(iso);
-  assert.equal(iso!.getTime(), usFormat!.getTime());
-});
-
-test("a date that is not a date is no expiry at all, never an Invalid Date", () => {
-  assert.equal(promoExpiryDate(""), null);
-  assert.equal(promoExpiryDate(null), null);
-  assert.equal(promoExpiryDate("whenever"), null);
-  // Month 13 rolls into the next year in JavaScript rather than failing, so
-  // it is caught explicitly - otherwise 13/01/2026 would read as Jan 2027.
-  assert.equal(promoExpiryDate("13/01/2026"), null);
-});
-
-// ---------------------------------------------------------------------------
-// Loading a record into the form, and building the body back out
-// ---------------------------------------------------------------------------
-
-test("the form loads from the record and does NOT carry the code", () => {
-  const values = promoCodeFormValues({
-    _id: "652f1a2b3c4d5e6f70819293",
-    code: "WELCOME2026",
-    description: "Launch offer",
-    type: "fixed",
-    fixed_rate: 12,
-    expiresAt: "12/31/2026",
-    status: "active",
-  });
-
-  assert.equal((values as any).code, undefined);
-  assert.deepEqual(values, {
-    description: "Launch offer",
-    type: "fixed",
-    fixed_rate: 12,
-    expiresAt: "12/31/2026",
-    tiers: [],
-  });
-});
-
-test("a tiered record keeps its bands; a fixed one is given none", () => {
-  const tiered = promoCodeFormValues({
-    type: "tiered",
-    tiers: [{ min: 1, max: 10, price: 9 }, { min: 11, max: 0, price: 7 }],
-  });
-  assert.equal(tiered.tiers.length, 2);
-  assert.deepEqual(tiered.tiers[1], { min: 11, max: 0, price: 7 });
-
-  // A code stored as fixed but carrying leftover bands must not send them:
-  // `promoCodeUpdateSchema` FORBIDS `tiers` on a fixed code and would 400.
-  const fixed = promoCodeFormValues({
-    type: "fixed",
-    fixed_rate: 5,
-    tiers: [{ min: 1, max: 10, price: 9 }],
-  });
-  assert.deepEqual(fixed.tiers, []);
-});
-
-test("an empty record gives a usable, valid, fixed-price form", () => {
-  const values = promoCodeFormValues(null);
-  assert.deepEqual(values, {
-    description: "",
-    type: "fixed",
-    fixed_rate: 0,
-    expiresAt: "",
-    tiers: [],
-  });
-  assert.equal(validatePromoCodeEdit(promoCodeUpdatePayload(values), NOW), null);
-});
-
-test("the payload never contains code, _id or status", () => {
-  const payload = promoCodeUpdatePayload({
-    description: "Launch offer",
-    type: "fixed",
-    fixed_rate: 12,
-    expiresAt: "12/31/2026",
-    tiers: [],
-  });
-
-  assert.deepEqual(Object.keys(payload).sort(), [
-    "description",
-    "expiresAt",
-    "fixed_rate",
-    "type",
-  ]);
-});
-
-test("a tiered payload sends bands and no fixed_rate, and the reverse", () => {
-  const tiered = promoCodeUpdatePayload({
-    description: "",
-    type: "tiered",
-    fixed_rate: 99,
-    expiresAt: "",
-    tiers: [{ min: 1, max: 10, price: 9 }],
-  });
-  assert.deepEqual(tiered.tiers, [{ min: 1, max: 10, price: 9 }]);
-  assert.equal("fixed_rate" in tiered, false);
-
-  const fixed = promoCodeUpdatePayload({
-    description: "",
-    type: "fixed",
-    fixed_rate: 9,
-    expiresAt: "",
-    tiers: [{ min: 1, max: 10, price: 9 }],
-  });
-  assert.equal("tiers" in fixed, false);
-  assert.equal(fixed.fixed_rate, 9);
-});
-
-test("a price nobody has typed is NOT quietly saved as free", () => {
-  // `Number("")` is 0. Coercing a blank field would turn "not filled in" into
-  // "every seat is free" - a real price, saved without anyone choosing it.
-  const payload = promoCodeUpdatePayload({
-    description: "",
-    type: "fixed",
-    fixed_rate: "" as any,
-    expiresAt: "",
-    tiers: [],
-  });
-  assert.equal(payload.fixed_rate, "");
-  assert.match(
-    String(validatePromoCodeEdit(payload, NOW)),
-    /Enter a price per seat/
-  );
-
-  // A deliberate 0, however, is a real answer and goes through.
-  const free = promoCodeUpdatePayload({
-    description: "",
-    type: "fixed",
-    fixed_rate: 0,
-    expiresAt: "",
-    tiers: [],
-  });
-  assert.equal(free.fixed_rate, 0);
-  assert.equal(validatePromoCodeEdit(free, NOW), null);
-});
-
-test("band numbers typed as text reach the API as numbers", () => {
-  const payload = promoCodeUpdatePayload({
-    description: "",
-    type: "tiered",
-    fixed_rate: 0,
-    expiresAt: "",
-    tiers: [{ min: "1", max: "10", price: "9.5" } as any],
-  });
-  assert.deepEqual(payload.tiers, [{ min: 1, max: 10, price: 9.5 }]);
-});
-
-// ---------------------------------------------------------------------------
-// What the form refuses, in the API's terms
-// ---------------------------------------------------------------------------
-
-test("a valid edit is refused nothing", () => {
-  assert.equal(
-    validatePromoCodeEdit(
-      { type: "fixed", fixed_rate: 0, expiresAt: "", description: "" },
-      NOW
-    ),
-    null
-  );
-  assert.equal(
-    validatePromoCodeEdit(
-      {
-        type: "tiered",
-        tiers: [{ min: 1, max: 10, price: 9 }, { min: 11, max: 0, price: 7 }],
-        expiresAt: "12/31/2026",
-      },
-      NOW
-    ),
-    null
-  );
-});
-
-test("an expiry already in the past is refused, and says what to do", () => {
-  const message = validatePromoCodeEdit(
-    { type: "fixed", fixed_rate: 5, expiresAt: "01/01/2020" },
-    NOW
-  );
-  assert.match(String(message), /already passed/);
-  assert.match(String(message), /clear the date/);
-});
-
-test("TODAY is not in the past - a code expiring today is still savable", () => {
-  assert.equal(
-    validatePromoCodeEdit(
-      { type: "fixed", fixed_rate: 5, expiresAt: "08/20/2026" },
-      NOW
-    ),
-    null
-  );
-});
-
-test("no expiry at all is allowed - that is a code with no end date", () => {
-  assert.equal(
-    validatePromoCodeEdit({ type: "fixed", fixed_rate: 5, expiresAt: "" }, NOW),
-    null
-  );
-});
-
-test("an unreadable expiry names the format instead of guessing", () => {
-  assert.match(
-    String(
-      validatePromoCodeEdit(
-        { type: "fixed", fixed_rate: 5, expiresAt: "next Tuesday" },
-        NOW
-      )
-    ),
-    /MM\/DD\/YYYY/
-  );
-});
-
-test("a free BAND is refused, because Joi's positive() refuses it", () => {
-  const message = validatePromoCodeEdit(
-    { type: "tiered", tiers: [{ min: 1, max: 10, price: 0 }] },
-    NOW
-  );
-  assert.match(String(message), /^Band 1: /);
-  assert.match(String(message), /above 0/);
-  // ...and it says the way to actually make seats free, which is the other
-  // pricing shape. `fixed_rate` is `min(0)`, not `positive()`.
-  assert.equal(
-    validatePromoCodeEdit({ type: "fixed", fixed_rate: 0 }, NOW),
-    null
-  );
-});
-
-test("the refused band is named, not just 'a band'", () => {
-  assert.match(
-    String(
-      validatePromoCodeEdit(
-        {
-          type: "tiered",
-          tiers: [
-            { min: 1, max: 10, price: 9 },
-            { min: 11, max: 5, price: 7 },
-          ],
-        },
-        NOW
-      )
-    ),
-    /^Band 2: /
-  );
-});
-
-test("a band with no upper limit is allowed - 0 means 'and above'", () => {
-  assert.equal(
-    validatePromoCodeEdit(
-      { type: "tiered", tiers: [{ min: 5, max: 0, price: 7 }] },
-      NOW
-    ),
-    null
-  );
-});
-
-test("a tiered code with no bands is refused, and offers the other shape", () => {
-  assert.match(
-    String(validatePromoCodeEdit({ type: "tiered", tiers: [] }, NOW)),
-    /at least one quantity band/
-  );
-});
-
-test("a negative fixed price is refused; a missing one is refused too", () => {
-  assert.match(
-    String(validatePromoCodeEdit({ type: "fixed", fixed_rate: -1 }, NOW)),
-    /cannot be less than 0/
-  );
-  assert.match(
-    String(validatePromoCodeEdit({ type: "fixed", fixed_rate: "" }, NOW)),
-    /Enter a price per seat/
-  );
-});
-
-test("a code with no pricing shape is refused first, before anything else", () => {
-  assert.equal(
-    validatePromoCodeEdit({ expiresAt: "01/01/2020" }, NOW),
-    "Choose how this code prices seats."
-  );
-});
-
-// ---------------------------------------------------------------------------
-// What a refusal from the server reads like
-// ---------------------------------------------------------------------------
-
-test("the API's own wording is what the screen shows", () => {
-  assert.equal(
-    promoCodeApiError(
-      { response: { _data: { message: "Promo code not found." } } },
-      "Could not save."
-    ),
-    "Promo code not found."
-  );
-});
-
-test("'Not authorized.' is replaced with something a person can act on", () => {
-  const message = promoCodeApiError(
-    { data: { message: "Not authorized." } },
-    "Could not save."
-  );
-  assert.match(message, /Seven365 staff account/);
-  assert.match(message, /Ask a Seven365 administrator/);
-});
-
-test("an unreadable failure falls back rather than dumping the error", () => {
-  assert.equal(
-    promoCodeApiError(new Error("fetch failed"), "Could not save the changes."),
-    "Could not save the changes."
-  );
-});
-
-// ---------------------------------------------------------------------------
-// The composable: verb, path and body of every write
-// ---------------------------------------------------------------------------
-
-const calls: Array<{ path: string; options: any }> = [];
-
-(globalThis as any).useNuxtApp = () => ({
-  $api: (path: string, options: any = {}) => {
-    calls.push({ path, options });
-    return Promise.resolve({ message: "ok" });
-  },
-});
-
-const promoCodeApi = (await import("../composables/usePromoCode.ts")).default();
-
-function lastCall() {
-  return calls[calls.length - 1];
-}
-
-const ID = "652f1a2b3c4d5e6f70819293";
-
-test("getById reads the one record, from the path the API mounts", async () => {
-  await promoCodeApi.getById(ID);
-  assert.equal(lastCall().path, `/api/promo-codes/id/${ID}`);
-  assert.equal(lastCall().options.method, "GET");
-});
-
-test("update is a PUT to /api/promo-codes/:id", async () => {
-  await promoCodeApi.update(ID, {
-    description: "Launch offer",
-    type: "fixed",
-    fixed_rate: 12,
-    expiresAt: "12/31/2026",
-  } as any);
-
-  assert.equal(lastCall().path, `/api/promo-codes/${ID}`);
-  assert.equal(lastCall().options.method, "PUT");
-  assert.equal(lastCall().options.body.description, "Launch offer");
-});
-
-test("update NEVER sends code, however it is called", async () => {
-  // The screen loads a record and could easily send it back whole. `code` is
-  // immutable on the server; sending it would be accepted and dropped, and
-  // the person would watch a rename succeed and change nothing.
-  await promoCodeApi.update(ID, {
-    code: "RENAMED",
-    type: "fixed",
-    fixed_rate: 1,
-  } as any);
-
-  assert.equal("code" in lastCall().options.body, false);
-  assert.equal(lastCall().options.body.type, "fixed");
-});
-
-test("updateStatus is a PATCH carrying only the new status", async () => {
-  await promoCodeApi.updateStatus(ID, "disabled");
-  assert.equal(lastCall().path, `/api/promo-codes/${ID}/status`);
-  assert.equal(lastCall().options.method, "PATCH");
-  assert.deepEqual(lastCall().options.body, { status: "disabled" });
-
-  await promoCodeApi.updateStatus(ID, "active");
-  assert.deepEqual(lastCall().options.body, { status: "active" });
-});
-
-test("remove is a DELETE, with no body to get wrong", async () => {
-  await promoCodeApi.remove(ID);
-  assert.equal(lastCall().path, `/api/promo-codes/${ID}`);
-  assert.equal(lastCall().options.method, "DELETE");
-  assert.equal(lastCall().options.body, undefined);
-});
-
-test("the four reads and writes are all on the composable", () => {
-  for (const name of [
-    "add",
-    "getPromoCodes",
-    "getByCode",
-    "getById",
-    "update",
-    "updateStatus",
-    "remove",
-  ]) {
-    assert.equal(
-      typeof (promoCodeApi as any)[name],
-      "function",
-      `usePromoCode() is missing ${name}`
-    );
-  }
-});

package/utils/promo-code-form.ts

@@ -1,246 +0,0 @@
-/**
- * THE STAFF CONSOLE'S PROMO CODE EDITOR, DECIDED IN ONE PLACE.
- *
- * A Seven365 staff member opens a code, changes what it prices or when it
- * stops, turns it off, turns it back on, or removes it. Everything the screen
- * has to be sure of before it sends the request is worked out here, so the
- * form and the API can never disagree about what is wrong.
- *
- * WHAT THE SERVER ACTUALLY ENFORCES, read from the merged backend rather than
- * assumed (`@7365admin1/core` `models/promo-code.model.ts` `promoCodeUpdate` /
- * `promoCodeUpdateSchema`, mounted by `API-core` as `PUT /api/promo-codes/:id`,
- * `PATCH /api/promo-codes/:id/status`, `DELETE /api/promo-codes/:id`):
- *
- *   - `code` is IMMUTABLE. The update schema accepts the key and drops it,
- *     because a subscription records the promo code it was bought with as
- *     text. The form must not offer to change it, or a person would watch a
- *     save succeed and the code stay as it was.
- *   - `type` is required and is "fixed" or "tiered".
- *   - a tiered code needs at least one band; every band starts at 1 or more,
- *     ends at or after where it starts (0 means "and above"), and is priced at
- *     MORE than 0 - Joi's `positive()`, so a free band is refused.
- *   - a fixed code needs a price of 0 or more; 0 is legal and means free.
- *   - `expiresAt` is free text to the server. It refuses nothing, which is
- *     exactly why a date already in the past is caught HERE: saving one is not
- *     an error, it is a code that silently stops working. Since core #1885 the
- *     shared lookup DOES refuse an expired or disabled code at checkout, so a
- *     past date is now a real off-switch rather than a decoration.
- *
- * Refusals are returned one at a time and in the API's order. A list of five
- * complaints about one form is harder to act on than the first thing to fix.
- *
- * Nothing here takes a card, quotes a total, or moves money. Red Dot is the
- * payment provider (owner decision 1); a promo code sets a price per seat.
- */
-
-// Imported rather than left to Nuxt's auto-import so this file also loads
-// under plain `node --test`, the same way `theme-aa-ledger.ts` imports
-// `theme.ts`. One reader of a failed request for the whole console.
-import { readApiError } from "./subscription-form.ts";
-
-/**
- * `expiresAt` is stored as free text and this console writes MM/DD/YYYY, but
- * nothing has ever stopped another caller storing ISO - so both are read.
- * Returns the END of the expiry day: a code dated today is good all of today.
- *
- * Deliberately the same rule as the org app's `utils/promo-code.js` and core's
- * `promo-code-currency.util.ts`. The three are separate copies on purpose -
- * the org app's is plain JS so `node --test` loads it directly, and core's
- * runs on the server - but they must never disagree in front of a customer,
- * so any change to one belongs in all three.
- */
-export function promoExpiryDate(value: any): Date | null {
-  if (!value) return null;
-  const raw = String(value).trim();
-  if (!raw) return null;
-
-  const parts = raw.match(/^(\d{1,2})\/(\d{1,2})\/(\d{4})$/);
-  if (parts) {
-    const [, m, d, y] = parts;
-    const date = new Date(Number(y), Number(m) - 1, Number(d), 23, 59, 59, 999);
-    // `new Date(2026, 12, ...)` rolls into the next year rather than failing.
-    return date.getMonth() === Number(m) - 1 ? date : null;
-  }
-
-  const iso = raw.match(/^(\d{4})-(\d{2})-(\d{2})$/);
-  if (iso) {
-    const [, y, m, d] = iso;
-    const date = new Date(Number(y), Number(m) - 1, Number(d), 23, 59, 59, 999);
-    return date.getMonth() === Number(m) - 1 ? date : null;
-  }
-
-  const parsed = new Date(raw);
-  return isNaN(parsed.getTime()) ? null : parsed;
-}
-
-/** Nothing typed yet. Not the same thing as a zero, which is a real price. */
-function isBlank(value: any): boolean {
-  return value === "" || value === null || value === undefined;
-}
-
-/** What the edit form holds while a person is filling it in. */
-export interface TPromoCodeFormValues {
-  description: string;
-  type: "fixed" | "tiered";
-  fixed_rate: number;
-  expiresAt: string;
-  tiers: Array<{ min: number; max: number; price: number }>;
-}
-
-/**
- * Pre-fill the form from the record the API sent back.
- *
- * `code` is not a form value - it is not editable, so it is displayed from the
- * record and never carried through the form where a change could reach it.
- */
-export function promoCodeFormValues(
-  record: Record<string, any> | null | undefined
-): TPromoCodeFormValues {
-  const promo = record ?? {};
-  const type = promo.type === "tiered" ? "tiered" : "fixed";
-
-  return {
-    description: String(promo.description ?? ""),
-    type,
-    fixed_rate: Number(promo.fixed_rate ?? 0),
-    expiresAt: String(promo.expiresAt ?? ""),
-    tiers:
-      type === "tiered" && Array.isArray(promo.tiers)
-        ? promo.tiers.map((tier: any) => ({
-            min: Number(tier?.min ?? 1),
-            max: Number(tier?.max ?? 0),
-            price: Number(tier?.price ?? 0),
-          }))
-        : [],
-  };
-}
-
-/**
- * The body `PUT /api/promo-codes/:id` takes, and nothing more.
- *
- * No `code`, no `_id`, no `status`. The API would accept and ignore all three;
- * not sending them means this screen cannot appear to change something it
- * cannot. `status` in particular has its own endpoint - folding it in here
- * would give two answers to "is this code on".
- */
-export function promoCodeUpdatePayload(
-  values: TPromoCodeFormValues
-): Record<string, any> {
-  const payload: Record<string, any> = {
-    description: values.description ?? "",
-    type: values.type,
-    expiresAt: values.expiresAt ?? "",
-  };
-
-  // The schema FORBIDS `tiers` on a fixed code, so each shape sends only the
-  // half that applies to it. `fixed_rate` is allowed either way but means
-  // nothing on a tiered code, and the server zeroes it there regardless.
-  if (values.type === "tiered") {
-    payload.tiers = (values.tiers ?? []).map((tier) => ({
-      min: Number(tier.min),
-      max: Number(tier.max),
-      price: Number(tier.price),
-    }));
-  } else {
-    // A blank price is passed through blank rather than quietly becoming 0.
-    // `Number("")` is 0, so coercing here would turn "they have not typed a
-    // price yet" into "every seat is free" - a real price, silently saved.
-    // The API refuses a blank `fixed_rate` too, so the two agree.
-    payload.fixed_rate = isBlank(values.fixed_rate)
-      ? ""
-      : Number(values.fixed_rate);
-  }
-
-  return payload;
-}
-
-/**
- * Everything that must be true before the request goes out. Returns the ONE
- * thing to tell the person, or `null` when there is nothing to tell them.
- */
-export function validatePromoCodeEdit(
-  payload: Record<string, any>,
-  now: Date = new Date()
-): string | null {
-  if (payload?.type !== "fixed" && payload?.type !== "tiered") {
-    return "Choose how this code prices seats.";
-  }
-
-  if (payload.type === "fixed") {
-    const rate = Number(payload.fixed_rate);
-    if (isBlank(payload.fixed_rate) || !Number.isFinite(rate)) {
-      return "Enter a price per seat. Use 0 to make every seat free.";
-    }
-    if (rate < 0) {
-      return "The price per seat cannot be less than 0.";
-    }
-  }
-
-  if (payload.type === "tiered") {
-    const tiers = Array.isArray(payload.tiers) ? payload.tiers : [];
-    if (!tiers.length) {
-      return "Add at least one quantity band, or switch this code to one price for every seat.";
-    }
-
-    for (let i = 0; i < tiers.length; i++) {
-      const band = tiers[i] ?? {};
-      const where = "Band " + (i + 1) + ": ";
-      const min = Number(band.min);
-      const max = Number(band.max);
-      const price = Number(band.price);
-
-      if (!Number.isInteger(min) || min < 1) {
-        return where + "a band has to start at 1 seat or more.";
-      }
-      if (!Number.isInteger(max) || max < 0) {
-        return (
-          where +
-          "the upper limit has to be a whole number of seats, or no limit."
-        );
-      }
-      // `max: 0` is how the band editor stores "and above" - not a band that
-      // ends at zero seats, which is why the API allows it.
-      if (max !== 0 && max < min) {
-        return (
-          where + "the upper limit cannot be lower than where the band starts."
-        );
-      }
-      if (!Number.isFinite(price) || price <= 0) {
-        return (
-          where +
-          "every band needs a price above 0. To make seats free, use one price for every seat and set it to 0."
-        );
-      }
-    }
-  }
-
-  if (payload.expiresAt) {
-    const expiry = promoExpiryDate(payload.expiresAt);
-    if (!expiry) {
-      return "The expiry date is not a date we can read. Use MM/DD/YYYY.";
-    }
-    if (expiry.getTime() < now.getTime()) {
-      return "That expiry date has already passed, so the code would stop working the moment it is saved. Pick a date in the future, or clear the date to remove the expiry.";
-    }
-  }
-
-  return null;
-}
-
-/**
- * Turn a refused request into something a person can act on.
- *
- * `readApiError` is what every other console screen uses, and the API's promo
- * messages are already written to be read - "Promo code not found.", "This
- * promo code has expired." Only one answer needs rewording: the staff guard
- * says "Not authorized.", which is true and tells nobody what to do next.
- */
-export function promoCodeApiError(error: any, fallback: string): string {
-  const message = readApiError(error, fallback);
-
-  if (/^not authorized\.?$/i.test(String(message).trim())) {
-    return "Your account is not a Seven365 staff account, so it cannot change promo codes. Ask a Seven365 administrator to make the change.";
-  }
-
-  return message;
-}