/* ============================================================ HRmaps Design System — BRIDGE OVERRIDES (hand-written) ------------------------------------------------------------ Additive. Loaded AFTER ds-bridge.css (so it wins for fields). Never modifies existing stylesheets. Holds rules that can't be auto-generated: form fields (dark-mode repaint), status labels, focus ring, and a dark-theme root safety-net. Light mode stays visually identical (tokens == legacy values); the dark-only block below is inert unless data-theme="dark". ============================================================ */ /* ---- BRAND KNOB FED BY THE PORTAL SETTING ------------------------------- `--primary` is the design system's single brand knob: every tint, state, focus ring — and, through the remap right below, the whole legacy `--primary-*` family — derives from it. Left at its stylesheet default it pinned the entire UI to HRmaps red. The portal has its own brand knob: "Couleur principale" in the global settings, which can be set for all entities or per entity. Which one applies to the current user is resolved SERVER-side (ApplyGlobalSettings → GetParsedSetting), lands in `UserSettings.primaryColor`, and mainCtrl injects the chosen palette entry on as `--light-primary-bg` / `--dark-primary-bg` (+ `-fg`). Feeding that into `--primary` is what makes the picked colour actually re-theme the app, instantly and everywhere. Read from the LEGACY vars rather than written from JS on purpose: the theme is per-container, not per-document — under `dark-sidebar` only the nav is dark, and a single inline `--primary` could not say two things at once. The `bg` variant (not `color`) is the solid brand fill, which is what `--primary` means here; the dark block of tokens/colors.css already derives the lightened text/tint variants from it. The fallback keeps HRmaps red when no colour is injected — login screen, or no global setting for this user — and must stay in sync with the default in tokens/colors.css. Consequence for the "one line per client" theming note in tokens/colors.css: a `:root { --primary }` override in a client stylesheet no longer has the last word, since this file loads after it. The in-product setting wins, on purpose — an admin changing the colour must see the colour change. */ :root { --primary: var(--light-primary-bg, #ED4337); --on-primary: var(--light-primary-fg, #ffffff); } [data-theme="dark"], [data-theme="dark-sidebar"] .nav-v2-container { --primary: var(--dark-primary-bg, #ED4337); --on-primary: var(--dark-primary-fg, #ffffff); } /* ---- APP TOKEN REMAP (modern v2 UI) ------------------------------------- The modern app has its OWN token system (predefinedClass.css) with a built-in light/dark theme via [data-theme=dark]. Its brand knob is --primary-color (=injected tenant indigo). We re-point the whole primary family onto the DS --primary so every modern screen follows the design system + the one-line tenant override, in BOTH light and dark. */ :root, [data-theme="dark"], [data-theme="dark-sidebar"] .nav-v2-container { --primary-color: var(--primary) !important; --primary-bg: var(--primary) !important; --primary-fg: var(--on-primary) !important; --primaryLight-bg: var(--primary-soft) !important; --primaryLight-fg: var(--primary-700) !important; /* ---- FAMILLE DES CHAMPS ----------------------------------------------- `sitecss.css` habille tous les champs natifs avec ces variables, et sous un selecteur enorme : select:not(.form-control):not(.cs-select):not(...) -> (0,12,1) Aucune recette du design system ne peut le battre sans repeter des classes a l infini. Mais elle n a pas a le battre : il suffit de brancher les VARIABLES qu il lit sur les tokens. C est la methode que prescrit le CLAUDE.md du design system — on branche l ancien CSS sur les tokens plutot que de le reecrire. Effet : tout champ natif de l application suit le theme et la couleur du client, y compris sur les ecrans non encore migres. Sans ce remappage, un