@7365admin1/layer-common 3.2.2-staging.153 → 3.2.2-staging.155

package/components/DashboardMain.vue

@@ -357,6 +357,29 @@
         </h2>
       </div>
 
+      <!--
+        THE TWO SERIES COLOURS STAY LITERAL, AND HERE IS WHY.
+
+        Everything else in this chart already follows the theme - the gridlines,
+        the axis labels and the ring around each dot are all Vuetify theme vars.
+        The two series are not, and they are the only chart colours in the file
+        that are still hexes.
+
+        They are left that way deliberately. The handoff names no chart palette
+        at all (searched: no "chart", no "legend", no "graph", and neither hex
+        appears anywhere in it), so the fallback rule is "use the token the
+        literal was already imitating". `#e53935` is plainly `--err`. `#ff9b9b`
+        is a second, softer red, and the palette has no second red - the only
+        other red token is `--err-bg`, a 10%-alpha FILL that would be invisible
+        as a 3px line. Re-pointing just one of them would collapse the pair in
+        dark mode, where `--err` is `rgb(229,115,115)` and would sit almost on
+        top of `#ff9b9b`'s `rgb(255,155,155)` - two lines the reader could no
+        longer tell apart. That is the same "do not merge two series into one
+        colour" trap as the Work Order Status bars below.
+
+        So: a two-series chart palette is missing from the design system, and
+        that is a designer question, not something to invent here.
+      -->
       <div v-if="hasChartData" class="mt-4" ref="chartContainerRef">
         <svg
           :viewBox="`0 0 ${chartWidth} 260`"
@@ -2473,6 +2496,29 @@ const todayAttentions = computed(() =>
   normalizeListItems(["todayAttentions", "attentions"])
 );
 
+/**
+ * THE WORK ORDER STATUS BARS.
+ *
+ * Was three hand-picked hexes - `#2fb84d` green, `#f12d2d` red, `#ff8900`
+ * orange - and blind to the theme: the SAME three bars in light and in dark,
+ * because a literal cannot follow a theme. Each is re-pointed at the token
+ * whose hue it was already imitating, which is the same treatment the KPI
+ * tiles got, and which keeps all three bars distinguishable.
+ *
+ * ONE OF THEM DOES NOT AGREE WITH `utils/status.ts`, ON PURPOSE.
+ * That file maps `completed -> ok` and `pending -> warn` (both honoured here),
+ * but it also maps `in progress -> warn` - the SAME tone as `pending`. Applying
+ * it literally would paint two of these three bars the same amber and make the
+ * chart unreadable, which is a regression, not a fix. So "In Progress" keeps
+ * the tone it is drawn in today (`--err`, the token `#f12d2d` was imitating)
+ * and this stays a colour change with no behaviour change.
+ *
+ * That leaves a real inconsistency to settle: on this very page the "In
+ * Progress" feedback CHIP is amber (`warn`) while this bar is red. Resolving it
+ * means either giving `in progress` its own tone in `utils/status.ts` - which
+ * is shared by every chip in the estate - or ruling that a chart series is not
+ * a status chip. Both are design decisions, so neither is taken here.
+ */
 const workOrderStatus = computed(() => {
   const summary = finalDashboardData.value?.workOrderStatusSummary;
   const metric = getMetric(["openWorkOrder", "workOrders", "workOrder"]);
@@ -2493,19 +2539,19 @@ const workOrderStatus = computed(() => {
       label: "Completed",
       value: completed,
       percent: (completed / max) * 100,
-      color: "#2fb84d",
+      color: "var(--ok)",
     },
     {
       label: "In Progress",
       value: inProgress,
       percent: (inProgress / max) * 100,
-      color: "#f12d2d",
+      color: "var(--err)",
     },
     {
       label: "Pending",
       value: pending,
       percent: (pending / max) * 100,
-      color: "#ff8900",
+      color: "var(--warn)",
     },
   ];
 });
@@ -3945,32 +3991,53 @@ function formatDashboardTime(value?: string) {
   text-transform: capitalize;
 }
 
-/* Was five pairs of literal pastels - the same pale green on the dark page,
-   and none of them the tones the rest of the product uses. */
+/* THESE FIVE ARE LITERAL ON PURPOSE - THE PRINT VIEW IS PAPER.
+ *
+ * `.print-dashboard-view` above pins its surface to `#ffffff` and its ink to
+ * `#1e293b` in BOTH themes, because a printed page is white however the app is
+ * themed. Putting the status tokens on these badges therefore did the opposite
+ * of what tokenising usually does: it let the SCREEN theme reach a surface that
+ * does not follow it. Measured on the print branch at 1440:
+ *
+ *   light  In Progress  rgb(59,111,212)  on rgb(235,241,251)  4.20:1
+ *   light  Completed    rgb(15,138,98)   on rgb(231,243,239)  3.82:1
+ *   dark   In Progress  rgb(125,166,236) on rgb(239,244,253)  2.23:1
+ *   dark   Completed    rgb(65,199,149)  on rgb(232,248,242)  1.93:1
+ *
+ * The dark rows are the defect: the dark-theme INK composited over the white
+ * paper the print view forces, so anyone who exports the dashboard while the
+ * app is in dark mode gets washed-out badges - 1.93:1, the lowest reading taken
+ * on this component. So these go back to fixed pastels, and specifically to the
+ * SAME five pairs the Word export writes into its own stylesheet further up, so
+ * the on-page print view and the exported document finally match.
+ *
+ * Same rule as the signature pad: a surface that does not follow the theme must
+ * not be painted with tokens that do.
+ */
 .badge-success {
-  background-color: var(--ok-bg);
-  color: var(--ok);
+  background-color: #d1fae5;
+  color: #065f46;
 }
 
 .badge-info {
-  background-color: var(--info-bg);
-  color: var(--info);
+  background-color: #e0f2fe;
+  color: #075985;
 }
 
 .badge-danger,
 .badge-error {
-  background-color: var(--err-bg);
-  color: var(--err);
+  background-color: #fee2e2;
+  color: #991b1b;
 }
 
 .badge-warning {
-  background-color: var(--warn-bg);
-  color: var(--warn);
+  background-color: #fef3c7;
+  color: #92400e;
 }
 
 .badge-neutral {
-  background-color: var(--hover);
-  color: var(--text2);
+  background-color: #f1f5f9;
+  color: #475569;
 }
 
 /* ------------------------------------------------------------------ */

package/components/HidEnabledGate.vue

@@ -1,14 +1,31 @@
+<!--
+  The gate that stands in for a whole screen when HID is not enabled for a site.
+
+  What it was: a raw `v-alert type="info" variant="tonal"` — Vuetify's own tonal
+  slab, at Vuetify's 4px radius, in Vuetify's font, on a Vuetify blue the theme
+  does not control. It is a full-screen state, not an inline warning.
+
+  DESIGN GAP, STATED: the handoff draws no "service not enabled" page. So this
+  is assembled from the established primitive rather than invented, exactly as
+  `PlaceholderComponent` was — `.screen-empty` (`assets/css/screens.css:149`) is
+  the design's centred, muted, 52px-padded block for "there is nothing to show
+  here", and the heading takes the `--fs-card-title` / `--fw-card-title` type
+  the design uses for every panel heading.
+
+  `.tone-info` sets `--tone-bg`; the icon's soft disc is the only thing that
+  paints with it, so the block keeps the informational colour without becoming
+  a coloured slab. Icons are translated centrally — no hand-mapping here.
+-->
 <template>
   <slot v-if="hidEnabled" />
 
-  <v-alert
-    v-else
-    type="info"
-    variant="tonal"
-    class="mt-6"
-    title="HID service is not enabled"
-    :text="message"
-  />
+  <div v-else class="screen-empty hid-gate">
+    <span class="hid-gate__icon tone-info">
+      <v-icon icon="mdi-information-outline" size="24" />
+    </span>
+    <h2 class="hid-gate__title">HID service is not enabled</h2>
+    <p class="hid-gate__body">{{ message }}</p>
+  </div>
 </template>
 
 <script setup lang="ts">
@@ -49,3 +66,40 @@ watchEffect(() => {
   );
 });
 </script>
+
+<style scoped>
+/* It replaces a screen's whole body, so it holds the viewport rather than
+   collapsing to the height of three lines. Same reason as PlaceholderComponent. */
+.hid-gate {
+  min-height: 40vh;
+}
+
+.hid-gate__icon {
+  display: inline-flex;
+  align-items: center;
+  justify-content: center;
+  width: 44px;
+  height: 44px;
+  border-radius: 50%;
+  background: var(--tone-bg);
+}
+
+/* `.screen-empty .v-icon` paints `--muted`; inside the tone scope the icon is
+   the informational colour, so it has to win that one-class rule. */
+.hid-gate .hid-gate__icon .v-icon {
+  color: var(--info);
+}
+
+.hid-gate__title {
+  margin: 0;
+  font-size: var(--fs-card-title);
+  font-weight: var(--fw-card-title);
+  color: var(--text);
+}
+
+.hid-gate__body {
+  max-width: 46ch;
+  margin: 0;
+  font-weight: var(--fw-cell);
+}
+</style>

package/composables/useFeedback.ts

@@ -51,9 +51,9 @@ export default function useFeedback() {
 
   const feedback = useState("feedback", () => new MFeedback());
   const feedbacks = useState("feedbacks", (): TFeedback[] => []);
-  const page = useState("page", () => 1);
-  const pages = useState("pages", () => 0);
-  const pageRange = useState("pageRange", () => "-- - -- of --");
+  const page = useState("feedbackPage", () => 1);
+  const pages = useState("feedbackPages", () => 0);
+  const pageRange = useState("feedbackPageRange", () => "-- - -- of --");
 
   function setFeedback(data?: TFeedback) {
     feedback.value = data || new MFeedback();

package/composables/useMember.ts

@@ -1,8 +1,8 @@
 export default function useMember() {
   const members = useState<Array<TMember>>("members", () => []);
-  const page = useState("page", () => 1);
-  const pages = useState("pages", () => 0);
-  const pageRange = useState("pageRange", () => "-- - -- of --");
+  const page = useState("memberPage", () => 1);
+  const pages = useState("memberPages", () => 0);
+  const pageRange = useState("memberPageRange", () => "-- - -- of --");
 
   const member = useState<TMember>("member", () => ({
     _id: "",

package/composables/useServiceProvider.ts

@@ -8,9 +8,9 @@ export default function useServiceProvider() {
     () => []
   );
 
-  const page = useState("page", () => 1);
-  const pages = useState("pages", () => 0);
-  const pageRange = useState("pageRange", () => "-- - -- of --");
+  const page = useState("serviceProviderPage", () => 1);
+  const pages = useState("serviceProviderPages", () => 0);
+  const pageRange = useState("serviceProviderPageRange", () => "-- - -- of --");
 
   const serviceProvider = useState(
     "serviceProvider",

package/composables/useWorkOrder.ts

@@ -57,9 +57,23 @@ export default function useWorkOrder() {
 
   const workOrder = useState("workOrder", () => new MWorkOrder());
   const workOrders = useState<Array<TWorkOrder>>("workOrders", () => []);
-  const page = useState("page", () => 1);
-  const pages = useState("pages", () => 0);
-  const pageRange = useState("pageRange", () => "-- - -- of --");
+  /*
+   * Namespaced, like every other composable in this folder (`facilityPage`,
+   * `commentPage`, `unit-billPage`). These three were registered on the bare
+   * keys "page" / "pages" / "pageRange", which `useState` treats as ONE
+   * app-global cell per key - so `useFeedback`, `useMember` and
+   * `useServiceProvider`, which register the same bare keys, were handed the
+   * very same refs. Two of those screens open at once and they share one page
+   * counter.
+   *
+   * Nothing depended on the collision: these three are never assigned anywhere
+   * in this composable, and `WorkOrder/ListView.vue` is the only file in the
+   * layer or in any of the 11 web apps that destructures them - every real
+   * work-order page keeps its own local `ref(1)`.
+   */
+  const page = useState("workOrderPage", () => 1);
+  const pages = useState("workOrderPages", () => 0);
+  const pageRange = useState("workOrderPageRange", () => "-- - -- of --");
 
   function setWorkOrder(data?: TWorkOrder) {
     workOrder.value = data || new MWorkOrder();

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.2-staging.153",
+  "version": "3.2.2-staging.155",
   "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.",