@oneuptime/common 12.0.30 → 12.0.32

package/Tests/App/Dashboard/EventOverlayHook.test.tsx

@@ -63,7 +63,9 @@ jest.mock(
 );
 
 import useEventTimeReferenceLines, {
+  EVENT_MARKER_TITLE_MAX_LENGTH,
   EventTimeReferenceLines,
+  truncateEventMarkerTitle,
 } from "../../../../App/FeatureSet/Dashboard/src/Components/Metrics/Utils/UseEventTimeReferenceLines";
 import ChartTimeReferenceLineProps from "../../../UI/Components/Charts/Types/TimeReferenceLineProps";
 import InBetween from "../../../Types/BaseDatabase/InBetween";
@@ -100,6 +102,8 @@ function Probe(props: {
             data-color={line.color}
             data-dash={line.strokeDasharray || "solid"}
             data-clickable={line.onClick ? "yes" : "no"}
+            data-kind={line.kind || "none"}
+            data-subtitle={line.subtitle || ""}
           >
             {line.label}
           </div>
@@ -194,6 +198,127 @@ describe("useEventTimeReferenceLines", () => {
     expect(deploy.dataset["clickable"]).toBe("no");
   });
 
+  test("markers carry the kind and subtitle the rail chip reads", async () => {
+    /*
+     * `kind` is what lets a chip holding a deploy AND an incident paint
+     * itself as the incident; `subtitle` is the card's second line. Both
+     * are additions — the label strings the surfaces reverse-engineer are
+     * deliberately unchanged.
+     */
+    getListMock.mockImplementation((args: { modelType: { name: string } }) => {
+      if (args.modelType.name === "Incident") {
+        return Promise.resolve({
+          data: [
+            {
+              id: new ObjectID("11111111-0000-4000-8000-000000000001"),
+              createdAt: "2026-08-20T10:10:00.000Z",
+              title: "API is down",
+              incidentSeverity: { name: "Sev1", color: "#123456" },
+            },
+          ],
+        });
+      }
+      return Promise.resolve({
+        data: [
+          {
+            id: new ObjectID("22222222-0000-4000-8000-000000000002"),
+            createdAt: "2026-08-20T10:20:00.000Z",
+            title: "High latency",
+            alertSeverity: { name: "Warning" },
+          },
+        ],
+      });
+    });
+    analyticsGetListMock.mockResolvedValue({
+      data: [
+        {
+          time: "2026-08-20T10:03:00.000Z",
+          title: "v2.31.0",
+          eventType: "deployment",
+        },
+      ],
+    });
+
+    render(<Probe enabled={true} window={WINDOW} />);
+
+    await waitFor(() => {
+      expect(screen.getByTestId("marker-count").textContent).toBe("3");
+    });
+
+    const markers: Array<HTMLElement> = screen.getAllByTestId("marker");
+    const byLabel: (needle: string) => HTMLElement = (
+      needle: string,
+    ): HTMLElement => {
+      const found: HTMLElement | undefined = markers.find(
+        (marker: HTMLElement) => {
+          return (marker.textContent || "").includes(needle);
+        },
+      );
+      if (!found) {
+        throw new Error(`no marker containing ${needle}`);
+      }
+      return found;
+    };
+
+    const incident: HTMLElement = byLabel("Incident: API is down");
+    expect(incident.dataset["kind"]).toBe("incident");
+    expect(incident.dataset["subtitle"]).toBe("Incident · Sev1");
+
+    const alert: HTMLElement = byLabel("Alert: High latency");
+    expect(alert.dataset["kind"]).toBe("alert");
+    expect(alert.dataset["subtitle"]).toBe("Alert · Warning");
+
+    const deploy: HTMLElement = byLabel("Deploy: v2.31.0");
+    expect(deploy.dataset["kind"]).toBe("change");
+    expect(deploy.dataset["subtitle"]).toBe("Change event");
+  });
+
+  test("a severity with no name still names the marker's kind", async () => {
+    getListMock.mockImplementation((args: { modelType: { name: string } }) => {
+      if (args.modelType.name === "Incident") {
+        return Promise.resolve({
+          data: [
+            {
+              id: new ObjectID("11111111-0000-4000-8000-000000000001"),
+              createdAt: "2026-08-20T10:10:00.000Z",
+              title: "API is down",
+              incidentSeverity: undefined,
+            },
+          ],
+        });
+      }
+      return Promise.resolve({ data: [] });
+    });
+    analyticsGetListMock.mockResolvedValue({ data: [] });
+
+    render(<Probe enabled={true} window={WINDOW} />);
+
+    await waitFor(() => {
+      expect(screen.getByTestId("marker-count").textContent).toBe("1");
+    });
+
+    const marker: HTMLElement = screen.getAllByTestId("marker")[0]!;
+    expect(marker.dataset["kind"]).toBe("incident");
+    expect(marker.dataset["subtitle"]).toBe("Incident");
+  });
+
+  test("a long title keeps enough of itself to be recognisable", () => {
+    /*
+     * The cap exists so a card listing a dozen clustered events stays
+     * scannable, not because the label has to fit inside the plot any
+     * more — it is generous now, and only bites well past a real title.
+     */
+    const ordinary: string = "Checkout API p99 latency breached its SLO";
+    expect(truncateEventMarkerTitle(ordinary)).toBe(ordinary);
+
+    const overlong: string = "x".repeat(EVENT_MARKER_TITLE_MAX_LENGTH + 20);
+    const truncated: string = truncateEventMarkerTitle(overlong);
+    expect(truncated.endsWith("…")).toBe(true);
+    expect(truncated.length).toBeLessThanOrEqual(
+      EVENT_MARKER_TITLE_MAX_LENGTH + 1,
+    );
+  });
+
   test("one source failing never takes the others down", async () => {
     getListMock.mockImplementation((args: { modelType: { name: string } }) => {
       if (args.modelType.name === "Incident") {

package/Tests/App/Dashboard/HeaderImageAssets.test.tsx

@@ -0,0 +1,93 @@
+import "@testing-library/jest-dom";
+import { render, screen } from "@testing-library/react";
+import React from "react";
+import { describe, expect, jest, test } from "@jest/globals";
+
+/*
+ * The shape esbuild's file-loader actually hands these components: the imported
+ * asset inlined as a "data:" URL (Common/UI/esbuild-config.js,
+ * createFileLoaderPlugin). Every existing suite that mocks an .svg mocks it as
+ * a plain path like "/blank-profile.svg" — which is exactly the shape that does
+ * NOT reproduce this bug, and why the whole test suite stayed green while every
+ * dashboard and admin page threw on first render.
+ *
+ * The "//" in the base64 payload is deliberate. Route collapses /+ into a
+ * single /, so the tempting "just let Route accept data: URLs" fix would
+ * silently corrupt the image — this payload makes that fix fail here too.
+ *
+ * ONE constant and ONE jest.mock for both assets on purpose: Common's
+ * jest.config.json maps every .svg to Tests/__mocks__/styleMock.js, so two
+ * jest.mock() calls naming two different .svg paths resolve to the same module
+ * and only the last factory would ever register.
+ */
+const ASSET_DATA_URL: string = "data:image/svg+xml;base64,////bG9nbw==";
+
+jest.mock("../../../UI/Images/logos/OneUptimeSVG/3-transparent.svg", () => {
+  return ASSET_DATA_URL;
+});
+
+import DashboardLogo from "../../../../App/FeatureSet/Dashboard/src/Components/Header/Logo";
+import AdminDashboardLogo from "../../../../App/FeatureSet/AdminDashboard/src/Components/Header/Logo";
+import Image from "../../../UI/Components/Image/Image";
+
+/*
+ * Regression cover for the crash that blocked every release from 2026-08-31.
+ *
+ * b2d2da71e8 taught Route to reject scheme-prefixed strings — correctly, it
+ * guards an open-redirect. But these components were laundering an <img> src
+ * through Route.fromString() purely to satisfy Image's prop type, and an
+ * esbuild-inlined asset src is always "data:"-prefixed. So Route threw during
+ * render, React unwound to the error boundary, and the dashboard never painted.
+ *
+ * An image src is not a Route. What these pin is that the header renders the
+ * asset straight through as an <img src>, with no Route in the path.
+ */
+describe("header image assets", () => {
+  test("the dashboard logo renders the inlined asset as its src", () => {
+    render(
+      <DashboardLogo
+        onClick={() => {
+          // no-op: the click target is not what regressed.
+        }}
+      />,
+    );
+
+    const logo: HTMLElement = screen.getByAltText("OneUptime");
+    expect(logo).toHaveAttribute("src", ASSET_DATA_URL);
+  });
+
+  test("the admin dashboard logo renders the inlined asset as its src", () => {
+    render(
+      <AdminDashboardLogo
+        onClick={() => {
+          // no-op
+        }}
+      />,
+    );
+
+    const logo: HTMLElement = screen.getByAltText("OneUptime");
+    expect(logo).toHaveAttribute("src", ASSET_DATA_URL);
+  });
+
+  /*
+   * Straight at the type misuse rather than at one component: any scheme-
+   * prefixed src has to survive <Image>. Before the fix this threw inside
+   * Route.fromString at the call sites; now the string reaches <img> untouched.
+   */
+  test("Image passes a data: URL through to src without validating it", () => {
+    render(<Image imageUrl={ASSET_DATA_URL} alt="asset" />);
+
+    expect(screen.getByAltText("asset")).toHaveAttribute("src", ASSET_DATA_URL);
+  });
+
+  /*
+   * An empty src must not fall through to the `file` branch and throw
+   * "file or imageUrl required" — it renders an empty <img>, keeping the node
+   * (and its test id) in the DOM.
+   */
+  test("an empty src renders an image rather than throwing", () => {
+    render(<Image imageUrl="" alt="empty" data-testid="empty-image" />);
+
+    expect(screen.getByTestId("empty-image")).toHaveAttribute("src", "");
+  });
+});

package/Tests/App/Dashboard/MonitorTemplateColumnAndFacet.test.tsx

@@ -80,11 +80,17 @@ jest.mock("../../../UI/Utils/User", () => {
 type CapturedTableProps = {
   columns?: Array<CapturedColumn> | undefined;
   query?: Record<string, unknown> | undefined;
+  userPreferencesKey?: string | undefined;
+  disableColumnCustomization?: boolean | undefined;
 };
 
 type CapturedColumn = {
   title: string;
   field?: Record<string, unknown> | undefined;
+  isHiddenByDefault?: boolean | undefined;
+  isNotCustomizable?: boolean | undefined;
+  hideOnMobile?: boolean | undefined;
+  disableCsvExport?: boolean | undefined;
   getElement?: ((item: Monitor) => ReactElement) | undefined;
   getExportValue?: ((item: Monitor) => string) | undefined;
 };
@@ -196,6 +202,16 @@ import {
   MONITOR_TEMPLATE_FACET_QUERY_FIELD,
 } from "../../../../App/FeatureSet/Dashboard/src/Components/Monitor/MonitorFacets";
 import { ResourceFacet } from "../../../../App/FeatureSet/Dashboard/src/Components/ResourceOwners/ResourceFacet";
+import Columns from "../../../UI/Components/ModelTable/Columns";
+import {
+  ColumnPreference,
+  CustomizableColumn,
+  applyColumnPreference,
+  getColumnBaseId,
+  getColumnIds,
+  getCustomizableColumns,
+} from "../../../UI/Components/ModelTable/ColumnPreference";
+import Column from "../../../UI/Components/ModelTable/Column";
 import Monitor from "../../../Models/DatabaseModels/Monitor";
 import MonitorTemplate from "../../../Models/DatabaseModels/MonitorTemplate";
 import Includes from "../../../Types/BaseDatabase/Includes";
@@ -372,6 +388,235 @@ describe("the Template column on the monitor list", () => {
   });
 });
 
+/*
+ * Issue #3491 shipped the column switched on, which put a stripe of "—" down
+ * the middle of every monitor list: most monitors are not created from a
+ * template, and the ones that are still only need the answer occasionally.
+ * It is now off by default and turned on from the Customize Columns picker.
+ * "Hidden" and "reachable" have to hold together — a column hidden on a table
+ * with no picker is a column nobody can get back — so these run the real
+ * ColumnPreference rules over the column set the table actually declares,
+ * rather than reading the flag on its own.
+ */
+describe("the Template column's place in a first-time viewer's table", () => {
+  type DeclaredColumnsFunction = () => Columns<Monitor>;
+
+  const declaredColumns: DeclaredColumnsFunction = (): Columns<Monitor> => {
+    return (capturedTableProps?.columns || []) as unknown as Columns<Monitor>;
+  };
+
+  type TemplateColumnIdFunction = () => string;
+
+  const templateColumnId: TemplateColumnIdFunction = (): string => {
+    const columns: Columns<Monitor> = declaredColumns();
+
+    const index: number = columns.findIndex((column: { title: string }) => {
+      return column.title === "Template";
+    });
+
+    return getColumnIds<Monitor>(columns)[index] as string;
+  };
+
+  type VisibleTitlesFunction = (
+    preference: ColumnPreference | null,
+  ) => Array<string>;
+
+  const visibleTitles: VisibleTitlesFunction = (
+    preference: ColumnPreference | null,
+  ): Array<string> => {
+    return applyColumnPreference<Monitor>({
+      columns: declaredColumns(),
+      preference,
+    }).map((column: { title: string }) => {
+      return column.title;
+    });
+  };
+
+  /*
+   * The flag only means something if the table persists a layout: without a
+   * `userPreferencesKey` the picker is never rendered (see
+   * BaseModelTable.isColumnCustomizationEnabled), so a hidden-by-default
+   * column would be a column nobody could ever get back.
+   */
+  test("is switchable back on, because the table has a column picker", async () => {
+    const props: CapturedTableProps = await renderTable({
+      projectId: PROJECT_ID,
+    });
+
+    expect(props.userPreferencesKey).toBeTruthy();
+    expect(props.disableColumnCustomization).toBeFalsy();
+    expect(columnTitled("Template")!.isNotCustomizable).toBeFalsy();
+  });
+
+  test("is not rendered for a viewer with no stored layout", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const titles: Array<string> = visibleTitles(null);
+
+    expect(titles).not.toContain("Template");
+    // Not because the table came back empty.
+    expect(titles).toContain("Name");
+    expect(titles).toContain("Monitor Status");
+    expect(titles).toContain("Labels");
+  });
+
+  test("is offered by the picker, switched off", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const entry: CustomizableColumn<Monitor> | undefined =
+      getCustomizableColumns<Monitor>({
+        columns: declaredColumns(),
+        preference: null,
+      }).find((candidate: CustomizableColumn<Monitor>) => {
+        return candidate.column.title === "Template";
+      });
+
+    expect(entry).toBeDefined();
+    expect(entry!.isVisible).toBe(false);
+    expect(entry!.isPinned).toBe(false);
+    /*
+     * Off, not gone: the picker must not offer to remove a column the table
+     * ships, because nothing would put it back.
+     */
+    expect(entry!.isRemovable).toBe(false);
+  });
+
+  test("stays on for a viewer who already switched it on", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const preference: ColumnPreference = {
+      order: [templateColumnId()],
+      hidden: [],
+    };
+
+    expect(visibleTitles(preference)).toContain("Template");
+  });
+
+  /*
+   * The id a viewer's "switch Template on" is stored under is the column's
+   * first field key, and getColumnIds breaks ties on that key with a title
+   * slug and then a POSITIONAL suffix. So the day someone adds a second column
+   * keyed on `monitorTemplate` - a "Template Version" column is entirely
+   * plausible - this column's persisted id changes under everyone who had it
+   * on, their stored entry stops matching, and the column falls back to its
+   * declared default, which is now off. Nobody would report that as a bug;
+   * they would just never see the column again.
+   */
+  test("has an id no other column competes for, so a stored layout keeps meaning it", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const columns: Columns<Monitor> = declaredColumns();
+    const ids: Array<string> = getColumnIds<Monitor>(columns);
+
+    const baseIds: Array<string> = columns.map((column: Column<Monitor>) => {
+      return getColumnBaseId<Monitor>(column);
+    });
+
+    // Nothing had to be disambiguated, so no id depends on declaration order.
+    expect(ids).toEqual(baseIds);
+
+    expect(
+      ids.filter((id: string) => {
+        return id === templateColumnId();
+      }),
+    ).toHaveLength(1);
+
+    /*
+     * Titles are the first tie-breaker, so two columns sharing one would push
+     * the tie down to position - and the picker would show the viewer two rows
+     * they cannot tell apart either.
+     */
+    const titles: Array<string> = columns.map((column: Column<Monitor>) => {
+      return column.title;
+    });
+
+    expect(new Set(titles).size).toBe(titles.length);
+  });
+
+  /*
+   * The upgrade path almost every real viewer takes: they arranged this table
+   * before the Template column existed, so their stored `order` simply has no
+   * entry for it and it has to stay off rather than appear uninvited. The
+   * generic rule is pinned in ColumnPreference's own tests; this pins it
+   * against the ids MonitorTable actually declares, so that giving the column
+   * an explicit `id` - which those generic tests would not notice - cannot
+   * quietly change what an existing layout resolves to.
+   */
+  test("stays off for a viewer whose layout predates the column", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const templateId: string = templateColumnId();
+
+    const preference: ColumnPreference = {
+      order: getColumnIds<Monitor>(declaredColumns()).filter((id: string) => {
+        return id !== templateId;
+      }),
+      hidden: [],
+    };
+
+    const titles: Array<string> = visibleTitles(preference);
+
+    expect(titles).not.toContain("Template");
+    // The rest of their arrangement survived, so this is not an empty result.
+    expect(titles).toContain("Name");
+    expect(titles).toContain("Labels");
+  });
+
+  /*
+   * `hideOnMobile` is enforced at render (Table/TableHeader and Table/TableRow
+   * drop the column outright) while the picker knows nothing about it, so a
+   * column carrying both flags is a dead control on a phone: the viewer ticks
+   * it, the shown-columns count goes up, and no column arrives. For a column
+   * that is hidden by default that is also a one-way door, since the picker is
+   * the only route back. Stated over the whole set so the next author cannot
+   * reintroduce the pair on a different column.
+   */
+  test("no column the picker can switch on is one the phone would throw away", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    const columns: Columns<Monitor> = declaredColumns();
+
+    /*
+     * An invariant over an empty set holds for the wrong reason, and this one
+     * is read off captured props - so prove the column it exists for is in
+     * there before believing the result.
+     */
+    expect(
+      columns.map((column: Column<Monitor>) => {
+        return column.title;
+      }),
+    ).toContain("Template");
+
+    const unreachable: Array<string> = columns
+      .filter((column: Column<Monitor>) => {
+        return (
+          Boolean(column.isHiddenByDefault) && Boolean(column.hideOnMobile)
+        );
+      })
+      .map((column: Column<Monitor>) => {
+        return column.title;
+      });
+
+    expect(unreachable).toEqual([]);
+  });
+
+  /*
+   * The default monitors CSV no longer carries a Template column, and it
+   * matters *why*: exports follow what is on screen (BaseModelTable attaches
+   * export keys only while walking the columns it is about to render), so the
+   * column leaves the CSV purely by being switched off, and comes back the
+   * moment the viewer switches it on. Someone chasing "the export lost the
+   * template" could reach for `disableCsvExport` or teach the exporter about
+   * visibility; both would break the column for the viewers who did switch it
+   * on. This records which lever is the real one.
+   */
+  test("does not opt out of the CSV", async () => {
+    await renderTable({ projectId: PROJECT_ID });
+
+    expect(columnTitled("Template")!.disableCsvExport).toBeFalsy();
+  });
+});
+
 describe("the Template chip in the monitor list's filter bar", () => {
   test("is one of the chips the bar is given", async () => {
     await renderTable({ projectId: PROJECT_ID });
@@ -503,3 +748,76 @@ describe("the same table scoped to one template", () => {
     expect(facetKeyed("monitorType")).toBeDefined();
   });
 });
+
+/*
+ * The two tables above are the same component with different column sets, and
+ * a saved layout records only the columns the picker was showing. Put those
+ * two facts together over one shared storage key and the template page becomes
+ * a trap: a viewer who tidies the Linked Monitors table writes a layout with
+ * no "monitorTemplate" entry in either `order` or `hidden`, and back on the
+ * monitors list a column named in neither list falls back to its declared
+ * default - which is now hidden. Their earlier "switch Template on" is gone,
+ * with no action that looks like it touched the monitors list.
+ *
+ * ModelTable is stubbed here, so no Save can be driven; what can be pinned is
+ * the precondition, and the precondition is what has to stay false.
+ */
+describe("the layout key each monitor table saves under", () => {
+  type ColumnIdsOfFunction = (props: CapturedTableProps) => Array<string>;
+
+  const columnIdsOf: ColumnIdsOfFunction = (
+    props: CapturedTableProps,
+  ): Array<string> => {
+    return getColumnIds<Monitor>(
+      (props.columns || []) as unknown as Columns<Monitor>,
+    );
+  };
+
+  test("cannot let the template page overwrite the monitor list's layout", async () => {
+    const unscoped: CapturedTableProps = await renderTable({
+      projectId: PROJECT_ID,
+    });
+
+    const unscopedKey: string | undefined = unscoped.userPreferencesKey;
+    const unscopedIds: Array<string> = columnIdsOf(unscoped);
+
+    /*
+     * A second render rather than a rerender: the two pages mount the table
+     * independently, and a stale capture would make this test agree with
+     * itself.
+     */
+    cleanup();
+    capturedTableProps = null;
+
+    const scoped: CapturedTableProps = await renderTable({
+      projectId: PROJECT_ID,
+      monitorTemplateId: TEMPLATE_ID,
+    });
+
+    const scopedKey: string | undefined = scoped.userPreferencesKey;
+    const scopedIds: Array<string> = columnIdsOf(scoped);
+
+    /*
+     * The invariant, stated so that either fix satisfies it: keep the two
+     * tables on separate keys, or make them offer the same columns. Only
+     * "shared key AND different columns" loses a viewer's choice.
+     */
+    const sharesKey: boolean = unscopedKey === scopedKey;
+    const offersSameColumns: boolean =
+      [...unscopedIds].sort().join(",") === [...scopedIds].sort().join(",");
+
+    expect(sharesKey && !offersSameColumns).toBe(false);
+
+    /*
+     * And the arrangement that satisfies it today, recorded so a rename of
+     * either key is a deliberate act - changing the unscoped key silently
+     * resets every existing viewer's monitor list layout.
+     */
+    expect(unscopedKey).toBe("monitors-table");
+    expect(scopedKey).toBe("monitor-template-monitors-table");
+
+    // The half of the invariant that is genuinely false, so it is the keys doing the work.
+    expect(unscopedIds).toContain("monitorTemplate");
+    expect(scopedIds).not.toContain("monitorTemplate");
+  });
+});