@oneuptime/common 12.0.31 → 12.0.33

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");
+  });
+});

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

@@ -121,7 +121,7 @@ describe("Monitor type picker", () => {
 
     /*
      * The whole point of the change. Every type used to render at once - nine
-     * headings and 29 cards, about six thousand pixels of them.
+     * headings and 31 cards, about six thousand pixels of them.
      */
     test("the long tail starts folded away behind its headings", () => {
       renderPicker();
@@ -175,7 +175,9 @@ describe("Monitor type picker", () => {
   describe("finding a type by the words a user already knows", () => {
     test.each([
       ["k8s", MonitorType.Kubernetes],
-      ["postgres", MonitorType.SQLQuery],
+      // An engine name means health series; "query" means the escape hatch.
+      ["postgres", MonitorType.Database],
+      ["query", MonitorType.SQLQuery],
       ["heartbeat", MonitorType.IncomingRequest],
       ["tls", MonitorType.SSLCertificate],
       ["snmp", MonitorType.NetworkDevice],