@7365admin1/layer-common 3.2.2-staging.122 → 3.2.2-staging.124

package/.changeset/camera-wall-plain-english.md

@@ -1,60 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/camera-wall-selection-and-guidance.md

@@ -1,65 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/config.json

@@ -1,11 +0,0 @@
-{
-  "$schema": "https://unpkg.com/@changesets/config@3.0.5/schema.json",
-  "changelog": "@changesets/cli/changelog",
-  "commit": false,
-  "fixed": [],
-  "linked": [],
-  "access": "public",
-  "baseBranch": "main",
-  "updateInternalDependencies": "patch",
-  "ignore": []
-}

package/.changeset/dark-primary-contrast.md

@@ -1,39 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/dashboard-dark-theme-contrast.md

@@ -1,15 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/notification-preferences.md

@@ -1,17 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/pm-sidebar-grouping-and-list-scaffold.md

@@ -1,27 +0,0 @@
----
-"@7365admin1/layer-common": patch
----
-
-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.

package/.changeset/service-provider-invitation-actions.md

@@ -1,28 +0,0 @@
----
-"@7365admin1/layer-common": minor
----
-
-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.

package/.editorconfig

@@ -1,12 +0,0 @@
-root = true
-
-[*]
-indent_size = 2
-indent_style = space
-end_of_line = lf
-charset = utf-8
-trim_trailing_whitespace = true
-insert_final_newline = true
-
-[*.md]
-trim_trailing_whitespace = false

package/.github/workflows/main.yml

@@ -1,17 +0,0 @@
-name: CI
-on:
-  push:
-    branches:
-      - "**"
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20.x
-          cache: "yarn"
-      - run: yarn install --frozen-lockfile && yarn dev:prepare
-      - run: yarn build

package/.github/workflows/publish-staging.yml

@@ -1,47 +0,0 @@
-name: Publish Staging
-on:
-  push:
-    branches:
-      - staging
-
-concurrency: ${{ github.workflow }}-${{ github.ref }}
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20.x
-          cache: "yarn"
-          cache-dependency-path: yarn.lock
-
-      - run: yarn install --immutable
-
-      - run: yarn build
-
-      - name: Create .npmrc for publishing
-        run: |
-          echo '//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}' > ~/.npmrc
-
-      - name: Set staging prerelease version
-        run: |
-          BASE=$(node -p "const [x,y,z]=require('./package.json').version.split('-')[0].split('.'); [x,y,+z+1].join('.')")
-          npm version "$BASE-staging.${{ github.run_number }}" --no-git-tag-version
-          node -p "'Publishing ' + require('./package.json').version"
-
-      - name: Publish to npm with staging tag
-        run: npm publish --tag staging --registry https://registry.npmjs.org
-
-      - name: Notify Discord on failure
-        if: failure()
-        env:
-          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
-        run: |
-          MESSAGE="@everyone :rotating_light: **Publish Staging** failed in \`${{ github.repository }}\` (\`${{ github.workflow }}\`)
-          ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
-          curl -s -X POST -H "Content-Type: application/json" \
-            -d "$(jq -n --arg content "$MESSAGE" '{content: $content}')" \
-            "$DISCORD_WEBHOOK_URL"

package/.github/workflows/publish.yml

@@ -1,39 +0,0 @@
-name: Publish
-on:
-  workflow_run:
-    workflows: [CI]
-    branches: [main]
-    types: [completed]
-
-concurrency: ${{ github.workflow }}-${{ github.ref }}
-
-permissions:
-  contents: write
-  pull-requests: write
-
-jobs:
-  publish:
-    if: ${{ github.event.workflow_run.conclusion == 'success' }}
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20.x
-          cache: "yarn" # Use yarn for caching
-          cache-dependency-path: yarn.lock # Cache Yarn lockfile
-
-      - run: yarn install --immutable # Install dependencies with immutable lockfile
-
-      - name: Create .npmrc for publishing
-        run: |
-          echo '//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}' > ~/.npmrc
-
-      - name: Create Release Pull Request or Publish
-        id: changesets
-        uses: changesets/action@v1
-        with:
-          publish: yarn release # Use yarn for publishing
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

package/PUBLISHING.md

@@ -1,269 +0,0 @@
-# Publishing Guide
-
-This document explains how to publish new versions of `@7365admin1/layer-common` to npm using changesets and GitHub Actions.
-
-## Overview
-
-The package uses an automated publishing workflow powered by [Changesets](https://github.com/changesets/changesets) and GitHub Actions. When you make changes and create a changeset, the workflow automatically:
-
-1. Creates a "Version Packages" PR with version bumps
-2. Publishes to npm when you merge that PR
-
-## Quick Start
-
-### 1. Make Your Changes
-
-Make your code changes in a new branch as usual.
-
-### 2. Create a Changeset
-
-Before committing, create a changeset to document your changes:
-
-```bash
-npx changeset
-```
-
-You'll be prompted to:
-- Select the type of change: `patch`, `minor`, or `major`
-- Write a summary of your changes
-
-This creates a `.changeset/[random-name].md` file.
-
-### 3. Commit and Push
-
-```bash
-git add .
-git commit -m "feat: your feature description"
-git push
-```
-
-### 4. Create a Pull Request
-
-Create a PR to merge your branch into `main`.
-
-### 5. Merge Your PR
-
-Once approved, merge your PR to `main`.
-
-### 6. Bot Creates Version PR (Automatic)
-
-After merging, the GitHub Actions bot will automatically:
-- Detect your changeset
-- Create a new PR titled "Version Packages"
-- Update `package.json` with the new version
-- Update `CHANGELOG.md`
-- Remove the changeset file
-
-### 7. Merge the Version PR
-
-Review and merge the "Version Packages" PR. This will:
-- Bump the version in `package.json`
-- Automatically publish to npm 🚀
-
-## Workflow Diagram
-
-```
-You: Make changes + create changeset
-         ↓
-You: Push and create PR
-         ↓
-You: Merge PR to main
-         ↓
-Bot: Creates "Version Packages" PR (automatic)
-         ↓
-You: Merge "Version Packages" PR
-         ↓
-Bot: Publishes to npm (automatic)
-```
-
-## Version Types
-
-When creating a changeset, you'll choose a version bump type:
-
-- **patch** (1.8.0 → 1.8.1): Bug fixes, minor changes
-- **minor** (1.8.0 → 1.9.0): New features, backward compatible
-- **major** (1.8.0 → 2.0.0): Breaking changes
-
-## Common Commands
-
-### Create a Changeset
-```bash
-npx changeset
-```
-
-### Create an Empty Changeset
-```bash
-npx changeset add --empty
-```
-
-### Check Which Packages Would Be Published
-```bash
-npx changeset status
-```
-
-### Manually Version (Local Testing Only)
-```bash
-npx changeset version
-```
-
-### Manually Publish (Not Recommended)
-```bash
-yarn run release
-```
-> ⚠️ **Note**: Manual publishing requires 2FA or an automation token. Use GitHub Actions instead.
-
-## GitHub Setup
-
-### Required Secrets
-
-The repository needs the following GitHub secret:
-
-**`NPM_TOKEN`**
-- Location: Settings → Secrets and variables → Actions
-- Type: Granular Access Token (Automation)
-- Value: Your npm automation token
-- Permissions: Read and Write for packages, with 2FA bypass enabled
-
-### Workflow Files
-
-- `.github/workflows/main.yml` - CI workflow (builds and tests)
-- `.github/workflows/publish.yml` - Publish workflow (creates PRs and publishes)
-
-## Configuration Files
-
-### `.changeset/config.json`
-
-```json
-{
-  "$schema": "https://unpkg.com/@changesets/config@3.0.5/schema.json",
-  "changelog": "@changesets/cli/changelog",
-  "commit": false,
-  "access": "public",
-  "baseBranch": "main"
-}
-```
-
-Key settings:
-- `"access": "public"` - Package is published as public (free)
-- `"baseBranch": "main"` - PRs are created against main
-
-### `package.json`
-
-```json
-{
-  "name": "@7365admin1/layer-common",
-  "version": "1.8.1",
-  "author": "7365admin1",
-  "publishConfig": {
-    "access": "public"
-  }
-}
-```
-
-Key settings:
-- `"publishConfig.access": "public"` - Ensures scoped package is public
-
-## Troubleshooting
-
-### "Version didn't update on npm"
-
-**Solution**: Make sure you merged the bot's "Version Packages" PR. The version only publishes after merging that PR, not your original PR.
-
-### "No Version Packages PR was created"
-
-**Possible causes**:
-1. No changeset file was committed
-2. CI workflow failed
-3. Check GitHub Actions logs for errors
-
-**Solution**: Run `npx changeset status` locally to verify changesets exist.
-
-### "402 Payment Required" Error
-
-**Cause**: Scoped packages (`@username/package`) are private by default and require payment.
-
-**Solution**: Ensure `publishConfig.access` is set to `"public"` in `package.json`.
-
-### "403 Forbidden" or "401 Unauthorized"
-
-**Cause**: Invalid or expired npm token.
-
-**Solution**: 
-1. Generate a new Granular Access Token (Automation type) on npmjs.com
-2. Update the `NPM_TOKEN` secret in GitHub
-3. Ensure token has "Bypass 2FA" enabled
-
-### "Changeset not found" Error
-
-**Cause**: Changeset file wasn't committed or was deleted.
-
-**Solution**: Run `npx changeset` again and commit the generated `.changeset/*.md` file.
-
-## Best Practices
-
-### 1. Always Create Changesets
-
-Never merge code changes without a changeset. It ensures:
-- Version tracking
-- Changelog updates
-- Proper npm publishing
-
-### 2. Write Clear Changeset Summaries
-
-Your changeset summary becomes the changelog entry. Make it:
-- Clear and concise
-- User-focused (what changed, not how)
-- Action-oriented (e.g., "Added X feature" not "Adding X feature")
-
-### 3. Don't Skip the Version PR
-
-Always review and merge the "Version Packages" PR. It shows exactly what will be published.
-
-### 4. Use Yarn for Local Development
-
-The project uses Yarn for dependency management:
-
-```bash
-yarn install
-yarn dev
-yarn build
-```
-
-### 5. Keep `.npmrc` Private
-
-The `.npmrc` file contains your authentication token. It's in `.gitignore` - **never commit it!**
-
-## Security
-
-### npm Authentication
-
-- **GitHub Actions**: Uses `NPM_TOKEN` secret (automation token)
-- **Local Publishing**: Uses `.npmrc` file (not committed to git)
-
-### Token Types
-
-- **Automation tokens**: Bypass 2FA, designed for CI/CD
-- **Publish tokens**: Require 2FA, for manual publishing
-
-Always use automation tokens for GitHub Actions.
-
-## Package Information
-
-- **Name**: `@7365admin1/layer-common`
-- **Registry**: https://registry.npmjs.org/
-- **Package Page**: https://www.npmjs.com/package/@7365admin1/layer-common
-- **Author**: 7365admin1
-- **License**: MIT
-
-## Need Help?
-
-If you encounter issues:
-
-1. Check the [Changesets documentation](https://github.com/changesets/changesets)
-2. Review GitHub Actions workflow logs
-3. Verify npm token is valid and has correct permissions
-4. Ensure `.changeset/config.json` has `"access": "public"`
-
----
-
-**Last Updated**: January 2026