@oneuptime/common 12.0.32 → 12.0.33

package/Tests/UI/Components/BasicRadioButtons.test.tsx

@@ -0,0 +1,336 @@
+// Components
+import BasicRadioButtons, {
+  BasicRadioButtonOption,
+} from "../../../UI/Components/RadioButtons/BasicRadioButtons";
+import { describe, expect, test } from "@jest/globals";
+import "@testing-library/jest-dom";
+import { fireEvent, render, screen } from "@testing-library/react";
+import React from "react";
+import getJestMockFunction, { MockFunction } from "../../../Tests/MockType";
+
+/*
+ * A regression suite for a bug that shipped and was visible on every desktop.
+ *
+ * The option title and its description were two inline spans inside one label,
+ * separated by `ml-1 sm:ml-0`. The `sm:` variant cancels the margin at every
+ * breakpoint from 640px up -- i.e. on every desktop -- so the only gap between
+ * the two strings disappeared and the pair rendered as one run-on sentence:
+ * "Create an alertNotifies the team and runs the on-call policy." The narrow
+ * phone layout, the one place the 4px margin survived, was the only place it
+ * looked right, which is why it went unnoticed.
+ *
+ * So the assertions below are about the two strings being separate, stacked
+ * block elements with no horizontal-margin hack between them. The rest of the
+ * suite pins the selection behaviour that these options exist to drive.
+ */
+
+const ALERT_TITLE: string = "Create an alert";
+const ALERT_DESCRIPTION: string =
+  "Notifies the team and runs the on-call policy.";
+const SILENT_TITLE: string = "Do nothing";
+const SILENT_DESCRIPTION: string = "Leaves the monitor silent.";
+
+const options: Array<BasicRadioButtonOption> = [
+  {
+    title: ALERT_TITLE,
+    description: ALERT_DESCRIPTION,
+    value: "alert",
+  },
+  {
+    title: SILENT_TITLE,
+    description: SILENT_DESCRIPTION,
+    value: "silent",
+  },
+];
+
+type RadioAtFunction = (index: number) => HTMLInputElement;
+
+/*
+ * Addressed by position because the suite also asserts things about the pair
+ * of elements at each index. Where the point of a test is the ASSOCIATION
+ * between a radio and its label, it queries by accessible name instead --
+ * see the "each radio is named by its own title" group.
+ */
+const radioAt: RadioAtFunction = (index: number): HTMLInputElement => {
+  const radio: HTMLElement | undefined = screen.getAllByRole("radio")[index];
+
+  if (!radio) {
+    throw new Error(`No radio button rendered at index ${index}.`);
+  }
+
+  return radio as HTMLInputElement;
+};
+
+describe("BasicRadioButtons", () => {
+  /*
+   * The label used to be a bare sibling of its input, with no htmlFor and
+   * without wrapping it, so nothing tied the two together. Two things followed
+   * from that, and neither was visible to a sighted mouse user: the radio had
+   * no accessible name at all -- a screen reader announced "radio button, not
+   * checked" and never read "Create an alert" -- and the only hit target was
+   * the 16px dot, so clicking the words did nothing.
+   */
+  describe("each radio is named by its own title", () => {
+    test("the radio can be found by its title", () => {
+      render(
+        <BasicRadioButtons
+          options={options}
+          onChange={getJestMockFunction()}
+        />,
+      );
+
+      expect(
+        screen.getByRole("radio", { name: new RegExp(ALERT_TITLE) }),
+      ).toBeInTheDocument();
+      expect(
+        screen.getByRole("radio", { name: new RegExp(SILENT_TITLE) }),
+      ).toBeInTheDocument();
+    });
+
+    test("no two radios share a name", () => {
+      render(
+        <BasicRadioButtons
+          options={options}
+          onChange={getJestMockFunction()}
+        />,
+      );
+
+      const first: HTMLElement = screen.getByRole("radio", {
+        name: new RegExp(ALERT_TITLE),
+      });
+      const second: HTMLElement = screen.getByRole("radio", {
+        name: new RegExp(SILENT_TITLE),
+      });
+
+      expect(first).not.toBe(second);
+    });
+
+    test("clicking the title text selects that option", () => {
+      const onChange: MockFunction = getJestMockFunction();
+
+      render(<BasicRadioButtons options={options} onChange={onChange} />);
+
+      onChange.mockClear();
+      fireEvent.click(screen.getByText(SILENT_TITLE));
+
+      expect(onChange).toHaveBeenCalledWith("silent");
+    });
+
+    test("clicking the description text selects that option too", () => {
+      const onChange: MockFunction = getJestMockFunction();
+
+      render(<BasicRadioButtons options={options} onChange={onChange} />);
+
+      onChange.mockClear();
+      fireEvent.click(screen.getByText(SILENT_DESCRIPTION));
+
+      expect(onChange).toHaveBeenCalledWith("silent");
+    });
+  });
+
+  describe("an option's title and description", () => {
+    /*
+     * The exact bug. `sm:ml-0` on the description is what glued the two strings
+     * together on desktop, and a horizontal margin is meaningless once the
+     * description is a block on its own line -- so its reappearance is the
+     * regression, whatever else changes around it.
+     */
+    test("the description is a block under the title, not an inline span nudged sideways", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(<BasicRadioButtons onChange={onChange} options={options} />);
+
+      const title: HTMLElement = screen.getByText(ALERT_TITLE);
+      const description: HTMLElement = screen.getByText(ALERT_DESCRIPTION);
+
+      expect(title).toHaveClass("block");
+      expect(description).toHaveClass("block");
+      expect(description.className).not.toContain("ml-1");
+      expect(description.className).not.toContain("sm:ml-0");
+    });
+
+    /*
+     * That an exact-match query for the title alone finds an element is the
+     * proof that the two strings are still two elements: fold them into one
+     * text node -- the shape the bug rendered as -- and this query finds
+     * nothing, because the node's text would be title + description.
+     */
+    test("the title is queryable on its own, and the description follows it", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(<BasicRadioButtons onChange={onChange} options={options} />);
+
+      const title: HTMLElement = screen.getByText(ALERT_TITLE);
+      const description: HTMLElement = screen.getByText(ALERT_DESCRIPTION);
+
+      expect(title).not.toBe(description);
+      expect(title.contains(description)).toBe(false);
+      expect(title.nextElementSibling).toBe(description);
+      expect(title.closest("label")).toBe(description.closest("label"));
+    });
+
+    /*
+     * `description` is optional, and an empty <span> still takes its `mt-0.5`
+     * with it -- which would leave a ragged extra gap under every title-only
+     * option in a list that mixes the two.
+     */
+    test("an option with no description renders no description element", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(
+        <BasicRadioButtons
+          onChange={onChange}
+          options={[{ title: SILENT_TITLE, value: "silent" }]}
+        />,
+      );
+
+      const label: HTMLLabelElement | null = screen
+        .getByText(SILENT_TITLE)
+        .closest("label");
+
+      expect(label).not.toBeNull();
+      expect(label?.children).toHaveLength(1);
+      expect(screen.getAllByRole("radio")).toHaveLength(1);
+    });
+  });
+
+  describe("selection", () => {
+    /*
+     * The whole point of the control: the form above it only learns which
+     * branch the user picked through onChange.
+     */
+    test("picking an option reports its value and checks only that radio", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(<BasicRadioButtons onChange={onChange} options={options} />);
+
+      fireEvent.click(radioAt(0));
+
+      expect(onChange).toHaveBeenLastCalledWith("alert");
+      expect(radioAt(0)).toBeChecked();
+      expect(radioAt(1)).not.toBeChecked();
+
+      fireEvent.click(radioAt(1));
+
+      expect(onChange).toHaveBeenLastCalledWith("silent");
+      expect(radioAt(0)).not.toBeChecked();
+      expect(radioAt(1)).toBeChecked();
+    });
+
+    /*
+     * A form that opens on a saved value has to show that value selected AND
+     * hand it back once, so the parent's state matches what is on screen
+     * before the user touches anything. Firing more than once here is not
+     * harmless: callers wire onChange to setState and to "mark form dirty".
+     */
+    test("initialValue selects that option on mount and reports it exactly once", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(
+        <BasicRadioButtons
+          onChange={onChange}
+          options={options}
+          initialValue="silent"
+        />,
+      );
+
+      expect(radioAt(1)).toBeChecked();
+      expect(radioAt(0)).not.toBeChecked();
+      expect(onChange).toHaveBeenCalledTimes(1);
+      expect(onChange).toHaveBeenCalledWith("silent");
+    });
+
+    /*
+     * No initial value means no pre-selected branch. A control that quietly
+     * checked the first option would submit a choice the user never made.
+     */
+    test("with no initialValue nothing is selected and the empty value is reported", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(<BasicRadioButtons onChange={onChange} options={options} />);
+
+      expect(radioAt(0)).not.toBeChecked();
+      expect(radioAt(1)).not.toBeChecked();
+      expect(onChange).toHaveBeenCalledWith("");
+    });
+
+    test("an empty-string initialValue also selects nothing", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(
+        <BasicRadioButtons
+          onChange={onChange}
+          options={options}
+          initialValue=""
+        />,
+      );
+
+      expect(radioAt(0)).not.toBeChecked();
+      expect(radioAt(1)).not.toBeChecked();
+      expect(onChange).toHaveBeenCalledWith("");
+    });
+  });
+
+  describe("per-option children", () => {
+    /*
+     * Options carry their own follow-up fields (pick an on-call policy, choose
+     * a status page). Showing them for an unchosen option would put inputs on
+     * screen that the form never reads; leaving them behind after the user
+     * switches branches is worse -- the stale field looks live and editable.
+     */
+    test("children appear only while their own option is checked", () => {
+      const childText: string = "Choose an on-call policy";
+      const onChange: MockFunction = getJestMockFunction();
+
+      render(
+        <BasicRadioButtons
+          onChange={onChange}
+          options={[
+            {
+              title: ALERT_TITLE,
+              description: ALERT_DESCRIPTION,
+              value: "alert",
+              children: <div>{childText}</div>,
+            },
+            {
+              title: SILENT_TITLE,
+              value: "silent",
+            },
+          ]}
+        />,
+      );
+
+      expect(screen.queryByText(childText)).not.toBeInTheDocument();
+
+      fireEvent.click(radioAt(0));
+
+      expect(screen.getByText(childText)).toBeInTheDocument();
+
+      fireEvent.click(radioAt(1));
+
+      expect(screen.queryByText(childText)).not.toBeInTheDocument();
+    });
+  });
+
+  describe("validation message", () => {
+    /*
+     * The error is the only feedback a user gets when a required choice was
+     * skipped; a swallowed message leaves a form that refuses to submit and
+     * says nothing about why.
+     */
+    test("the error prop renders its message", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(
+        <BasicRadioButtons
+          onChange={onChange}
+          options={options}
+          error="Pick one of these."
+        />,
+      );
+
+      expect(screen.getByTestId("error-message")).toHaveTextContent(
+        "Pick one of these.",
+      );
+    });
+
+    test("no error element is rendered when there is no error", () => {
+      const onChange: MockFunction = getJestMockFunction();
+      render(<BasicRadioButtons onChange={onChange} options={options} />);
+
+      expect(screen.queryByTestId("error-message")).not.toBeInTheDocument();
+    });
+  });
+});

package/Tests/UI/Components/MonitorTemplateVariables/TemplateVariablesCatalog.test.ts

@@ -234,6 +234,21 @@ const PER_TYPE_EXPECTATIONS: Array<PerTypeExpectation> = [
       "failureCause",
     ],
   },
+  {
+    monitorType: MonitorType.Database,
+    title: "Database Health",
+    keys: [
+      "isOnline",
+      "responseTimeInMs",
+      "failureCause",
+      "connectionError",
+      "engineVersion",
+      "collectedGroups",
+      "unavailableGroups",
+      "collectionIssueSummary",
+      "metrics",
+    ],
+  },
   {
     monitorType: MonitorType.ExternalStatusPage,
     title: "External Status Page",

package/Tests/UI/Components/ProgressBar.test.tsx

@@ -27,10 +27,46 @@ describe("ProgressBar Component", () => {
     expect(countText.innerHTML).toEqual("30 of 99 items");
   });
 
-  test("should handle zero total count without crashing", () => {
+  /*
+   * A zero total reads as an empty track, not a full one.
+   *
+   * JavaScript does not throw on a divide by zero, so before the component
+   * guarded the total this arithmetic produced Infinity (capped to a
+   * misleading 100%) or, for a zero count, NaN — which reached the DOM three
+   * times over: `width: NaN%`, which the browser discards, aria-valuenow, and
+   * a visible "NaN%" beside the count. Nothing to do is nothing done, so 0 is
+   * the honest reading and it is what every branch below asserts.
+   */
+  test("shows an empty bar when the total is zero", () => {
     render(<ProgressBar count={30} totalCount={0} suffix="items" />);
     const progressBar: HTMLElement = getProgressBar();
-    expect(progressBar).toHaveStyle({ width: "100%" });
+    expect(progressBar).toHaveStyle({ width: "0%" });
+  });
+
+  test("shows an empty bar when both the count and the total are zero", () => {
+    render(<ProgressBar count={0} totalCount={0} suffix="items" />);
+    const progressBar: HTMLElement = getProgressBar();
+    expect(progressBar).toHaveStyle({ width: "0%" });
+  });
+
+  test("never renders NaN to the user when the total is zero", () => {
+    const { container } = render(
+      <ProgressBar count={0} totalCount={0} suffix="items" />,
+    );
+
+    // The readout, the aria value and the width - the three NaN reached.
+    expect(container.textContent).not.toContain("NaN");
+    expect(screen.getByRole("progressbar")).toHaveAttribute(
+      "aria-valuenow",
+      "0",
+    );
+    expect(getProgressBar()).toHaveStyle({ width: "0%" });
+  });
+
+  test("a negative total is treated as nothing to do, not as progress", () => {
+    render(<ProgressBar count={5} totalCount={-10} suffix="items" />);
+    const progressBar: HTMLElement = getProgressBar();
+    expect(progressBar).toHaveStyle({ width: "0%" });
   });
 
   test("should round up the percentage to the nearest integer", () => {

package/Tests/UI/Components/SideMenuItem.test.tsx

@@ -5,19 +5,26 @@ import SideMenuItem, {
   ComponentProps,
 } from "../../../UI/Components/SideMenu/SideMenuItem";
 import * as Navigation from "../../../UI/Utils/Navigation";
-import { describe, expect, afterEach, jest } from "@jest/globals";
+import { describe, expect, it, afterEach, jest } from "@jest/globals";
 import "@testing-library/jest-dom";
 import { fireEvent, render, screen } from "@testing-library/react";
 // Types
 import Route from "../../../Types/API/Route";
+import URL from "../../../Types/API/URL";
 import IconProp from "../../../Types/Icon/IconProp";
 import React from "react";
 import getJestMockFunction from "../../../Tests/MockType";
 
-const highlightClassList: string =
-  "bg-gradient-to-r from-indigo-50 to-indigo-50/50 text-indigo-700 shadow-sm";
+/*
+ * The active-row treatment, pinned here because it is the only thing that
+ * tells a user which page they are on. A flat indigo ground plus semibold
+ * text replaced the earlier gradient-and-shadow: the shadow read as a raised
+ * card inside a card, and the gradient's second stop was invisible at the
+ * width the menu actually renders at.
+ */
+const highlightClassList: string = "bg-indigo-50 text-indigo-700 font-semibold";
 
-const subItemHighlightClassList: string = "bg-indigo-50/70 text-indigo-700";
+const subItemHighlightClassList: string = "bg-indigo-50 text-indigo-700";
 
 jest.mock("../../../UI/Utils/Navigation.ts", () => {
   return {
@@ -192,4 +199,219 @@ describe("Side Menu Item", () => {
       .closest("a");
     expect(subLinkElement).toHaveClass(subItemHighlightClassList);
   });
+
+  /*
+   * The redesigned row: a bare icon, a truncating title span, and indicators
+   * that carry no text. Each of the three is depended on somewhere outside
+   * this component, so a well-meaning restyle breaks a suite that says nothing
+   * about side menus.
+   */
+  describe("Redesigned row layout", () => {
+    type SetActivePageFunction = (activeRoute: Route | URL | null) => void;
+
+    /*
+     * Every test below states the active page for itself instead of inheriting
+     * whatever mock the previous test left on the module -- jest.clearAllMocks
+     * clears calls, not implementations, so an inherited mockReturnValue(true)
+     * would quietly turn a "this row is not highlighted" assertion into a test
+     * of nothing.
+     */
+    const setActivePage: SetActivePageFunction = (
+      activeRoute: Route | URL | null,
+    ): void => {
+      Navigation.default.isOnThisPage =
+        getJestMockFunction().mockImplementation((to: Route | URL): boolean => {
+          return activeRoute !== null && to === activeRoute;
+        });
+    };
+
+    const longLink: {
+      title: string;
+      to: Route;
+    } = {
+      title: "Scheduled Maintenance",
+      to: new Route("/scheduled-maintenance"),
+    };
+
+    /*
+     * `span.truncate` is a read interface, not just an ellipsis.
+     * SideMenuHarness.linksIn() takes a row's title from `span.truncate` and
+     * falls back to the anchor's whole textContent when it is missing -- so
+     * dropping the class does not fail here, it makes five product menu suites
+     * expect "Scheduled Maintenance" and read "Scheduled Maintenance12".
+     */
+    it("Should keep the title in span.truncate with the badge digits outside it", () => {
+      setActivePage(null);
+
+      const badgeCount: number = 12;
+      render(
+        <SideMenuItem
+          link={longLink}
+          icon={IconProp.Home}
+          badge={badgeCount}
+          badgeType={BadgeType.DANGER}
+        />,
+      );
+
+      const mainLink: HTMLAnchorElement = screen
+        .getByText(longLink.title)
+        .closest("a") as HTMLAnchorElement;
+
+      const titleSpan: HTMLSpanElement | null =
+        mainLink.querySelector("span.truncate");
+
+      expect(titleSpan).not.toBeNull();
+      expect(titleSpan?.textContent).toBe(longLink.title);
+      expect(titleSpan?.textContent).not.toContain(String(badgeCount));
+
+      // The badge is inside the same anchor, which is why the span is needed.
+      expect(mainLink.textContent).toContain(String(badgeCount));
+      expect(mainLink.textContent).not.toBe(longLink.title);
+    });
+
+    /*
+     * The icon is drawn bare. A filled chip around it cost ~28px of a 208px
+     * menu, and that is the width the long titles above were losing to the
+     * ellipsis -- so a chip coming back is a layout regression, not a taste
+     * question.
+     */
+    it("Should render the icon without a filled chip behind it", () => {
+      setActivePage(null);
+
+      const { container } = render(
+        <SideMenuItem {...defaultProps} icon={IconProp.Home} />,
+      );
+
+      const mainLink: HTMLAnchorElement = container.querySelector(
+        "a",
+      ) as HTMLAnchorElement;
+
+      expect(mainLink.querySelector("svg")).not.toBeNull();
+      expect(mainLink.querySelector(".bg-gray-100")).toBeNull();
+      expect(mainLink.querySelector(".bg-indigo-100")).toBeNull();
+    });
+
+    // The active row is where a tinted chip is most tempting, and costs the same width.
+    it("Should render the active row's icon without a filled chip either", () => {
+      setActivePage(defaultProps.link.to);
+
+      const { container } = render(
+        <SideMenuItem {...defaultProps} icon={IconProp.Home} />,
+      );
+
+      const mainLink: HTMLAnchorElement = container.querySelector(
+        "a",
+      ) as HTMLAnchorElement;
+
+      expect(mainLink).toHaveClass(highlightClassList);
+      expect(mainLink.querySelector(".bg-indigo-100")).toBeNull();
+      expect(mainLink.querySelector(".bg-gray-100")).toBeNull();
+    });
+
+    /*
+     * The other half of the highlight assertion above. Without this, a row that
+     * painted itself active unconditionally would still pass the positive test
+     * -- and the menu would tell the user they are on every page at once.
+     */
+    it("Should not highlight the main link when on a different page", () => {
+      setActivePage(null);
+
+      render(<SideMenuItem {...defaultProps} />);
+
+      const mainLink: HTMLAnchorElement | null = screen
+        .getByText(defaultProps.link.title)
+        .closest("a");
+
+      expect(mainLink).not.toHaveClass("bg-indigo-50");
+      expect(mainLink).not.toHaveClass("text-indigo-700");
+      expect(mainLink).not.toHaveClass("font-semibold");
+      expect(mainLink).toHaveClass("text-gray-600");
+    });
+
+    /*
+     * A sub-item is a different page from its parent. Highlighting both would
+     * leave two rows claiming to be the current page, which is precisely the
+     * question the highlight exists to answer.
+     */
+    it("Should leave the main link unhighlighted when only the sub item is active", () => {
+      const subLink: {
+        title: string;
+        to: Route;
+      } = {
+        title: "Sub Page",
+        to: new Route("/sub-page"),
+      };
+
+      setActivePage(subLink.to);
+
+      render(<SideMenuItem {...defaultProps} subItemLink={subLink} />);
+
+      const mainLink: HTMLAnchorElement | null = screen
+        .getByText(defaultProps.link.title)
+        .closest("a");
+      const subLinkElement: HTMLAnchorElement | null = screen
+        .getByText(subLink.title)
+        .closest("a");
+
+      expect(subLinkElement).toHaveClass(subItemHighlightClassList);
+      expect(mainLink).not.toBe(subLinkElement);
+      expect(mainLink).not.toHaveClass("bg-indigo-50");
+      expect(mainLink).not.toHaveClass("text-indigo-700");
+    });
+
+    /*
+     * "Something is wrong here" and "something needs attention here" are
+     * different messages, and colour alone is not enough to tell them apart --
+     * the two indicators have to be different glyphs as well.
+     */
+    it("Should render alert and warning as distinguishable indicators", () => {
+      setActivePage(null);
+
+      const withAlert: HTMLElement = render(
+        <SideMenuItem {...defaultProps} showAlert={true} />,
+      ).container;
+      const withWarning: HTMLElement = render(
+        <SideMenuItem {...defaultProps} showWarning={true} />,
+      ).container;
+
+      const alertIcon: SVGElement | null =
+        withAlert.querySelector("svg.text-red-500");
+      const warningIcon: SVGElement | null =
+        withWarning.querySelector("svg.text-amber-500");
+
+      expect(alertIcon).not.toBeNull();
+      expect(warningIcon).not.toBeNull();
+      expect(withAlert.querySelector("svg.text-amber-500")).toBeNull();
+      expect(withWarning.querySelector("svg.text-red-500")).toBeNull();
+      expect(alertIcon?.innerHTML).not.toBe(warningIcon?.innerHTML);
+    });
+
+    /*
+     * Neither indicator may put TEXT inside the anchor.
+     * Common/Tests/App/Dashboard/AdminUserOnCallPages.test.tsx reads
+     * anchor.textContent as the row's title, so a screen-reader label rendered
+     * as visible text here ("Alert", "!") fails that unrelated suite instead of
+     * this one.
+     */
+    it("Should add no text to the anchor for the alert and warning indicators", () => {
+      setActivePage(null);
+
+      const { container } = render(
+        <SideMenuItem
+          {...defaultProps}
+          icon={IconProp.Home}
+          showAlert={true}
+          showWarning={true}
+        />,
+      );
+
+      const mainLink: HTMLAnchorElement = container.querySelector(
+        "a",
+      ) as HTMLAnchorElement;
+
+      expect(mainLink.textContent?.trim()).toBe(defaultProps.link.title);
+      // Row icon plus both indicators, all drawn as inline <svg>.
+      expect(mainLink.querySelectorAll("svg")).toHaveLength(3);
+    });
+  });
 });