fix(ui): unify error-banner recipe, portal chrome tokens, portal name, 404 #478

Merged

nrupard merged 1 commit from fix/MAPPS-412-copy-token into main

2026-08-05 18:54:19 +02:00

nrupard commented

2026-08-05 18:31:22 +02:00

Owner

Implements MAPPS-412 (2026-08-04 mokosh-apps UI audit, F3/F4/F27/F28): copy and token drift. 6 files.

F3 - one error-banner recipe

The two tickets.rs error banners that used the divergent dark recipe (dark:bg-red-900/30 border-red-800) now match the app-wide recipe (dark:bg-red-950/30 border-red-900), so every inline error banner uses one recipe. Extracting a shared component to de-duplicate the ~58 hand-rolled copies (the durable fix) is tracked in MAPPS-418.

F4 - app-chrome hues use tokens

The three portal quick-action tiles used arbitrary blue/green/purple with no semantic logic; they now use the accent scale (bg-accent-50 dark:bg-accent-900/20 hover:bg-accent-100 dark:hover:bg-accent-900/40, text-accent icon, text-accent-900 dark:text-accent-100 label), so the portal chrome is tokenized.

No action, with reason:

home.rs marketing lines (blue/indigo gradient): the theme-guard script (scripts/check-theme-tokens.sh, not a CI gate) flags only bg-white/gray-*. These lines use neither, so they need no opt-out marker; the bg-white sibling CTAs that DO trip the script already carry theme-guard-allow, so the marketing opt-outs are already consistently marked.
the three purples (Planning status badge, calendar meeting data-viz which is already theme-guard-allow, table badge) are semantically distinct and unflagged; unifying them to one token would be wrong.

F27 - one portal name

The client-facing area is now named "Client Portal" in every user-visible label: the portal-login heading, and the set-password page's four "the portal" / "customer portal" strings, plus one more "customer portal" label found by sweep in contacts.rs. Generic-prose references ("submitting tickets from the portal", "arrives through the portal") are left as idiomatic common-noun usage, and the internal portal-token / portal-flag strings are technical, not client-area names.

F28 - portal-aware, correctly-cased 404

The shared 404 now title-cases "Knowledge Base" and offers a "Go to Client Portal" (PortalHome) destination alongside Dashboard and Home.

Verification

Diff-reviewed (no local cargo): Route::PortalHome exists, all accent-scale tokens (accent-50/100/900) are defined in input.css, no "customer portal" label remains, no em-dash. CI runs fmt/clippy(-D warnings)/wasm-build/tests.

#MAPPS-412

Implements MAPPS-412 (2026-08-04 mokosh-apps UI audit, F3/F4/F27/F28): copy and token drift. 6 files. ## F3 - one error-banner recipe The two `tickets.rs` error banners that used the divergent dark recipe (`dark:bg-red-900/30 border-red-800`) now match the app-wide recipe (`dark:bg-red-950/30 border-red-900`), so every inline error banner uses one recipe. Extracting a shared component to de-duplicate the ~58 hand-rolled copies (the durable fix) is tracked in MAPPS-418. ## F4 - app-chrome hues use tokens The three portal quick-action tiles used arbitrary blue/green/purple with no semantic logic; they now use the accent scale (`bg-accent-50 dark:bg-accent-900/20 hover:bg-accent-100 dark:hover:bg-accent-900/40`, `text-accent` icon, `text-accent-900 dark:text-accent-100` label), so the portal chrome is tokenized. No action, with reason: - home.rs marketing lines (blue/indigo gradient): the theme-guard script (`scripts/check-theme-tokens.sh`, not a CI gate) flags only `bg-white`/`gray-*`. These lines use neither, so they need no opt-out marker; the `bg-white` sibling CTAs that DO trip the script already carry `theme-guard-allow`, so the marketing opt-outs are already consistently marked. - the three purples (Planning status badge, calendar meeting data-viz which is already `theme-guard-allow`, table badge) are semantically distinct and unflagged; unifying them to one token would be wrong. ## F27 - one portal name The client-facing area is now named "Client Portal" in every user-visible label: the portal-login heading, and the set-password page's four "the portal" / "customer portal" strings, plus one more "customer portal" label found by sweep in contacts.rs. Generic-prose references ("submitting tickets from the portal", "arrives through the portal") are left as idiomatic common-noun usage, and the internal portal-token / portal-flag strings are technical, not client-area names. ## F28 - portal-aware, correctly-cased 404 The shared 404 now title-cases "Knowledge Base" and offers a "Go to Client Portal" (PortalHome) destination alongside Dashboard and Home. ## Verification Diff-reviewed (no local cargo): `Route::PortalHome` exists, all accent-scale tokens (`accent-50/100/900`) are defined in input.css, no "customer portal" label remains, no em-dash. CI runs fmt/clippy(-D warnings)/wasm-build/tests. #MAPPS-412

nrupard added 1 commit

2026-08-05 18:31:22 +02:00

fix(ui): unify error-banner recipe, portal chrome tokens, portal name, 404

Check / fmt + clippy + tests (pull_request) Successful in 1m21s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

ecc761f8b4

Implements MAPPS-412 (2026-08-04 UI audit F3/F4/F27/F28). Aligns the two divergent tickets.rs error banners to the app-wide dark recipe; tokenizes the three portal quick-action tiles from arbitrary blue/green/purple to the accent scale; normalizes every user-visible "the portal"/"customer portal" label to "Client Portal" (leaving idiomatic common-noun references and internal token/flag strings); and makes the shared 404 title-case "Knowledge Base" and offer a Client Portal destination. The home.rs marketing lines and the three semantic purples are classified no-action (unflagged by the theme script / distinct meanings); the shared ErrorBanner component is tracked in MAPPS-418.

#MAPPS-412