@oneuptime/common 12.0.31 → 12.0.33

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

@@ -14,6 +14,7 @@ import {
   NetworkTopologyEdge,
   NetworkTopologyNode,
 } from "../../../Types/Monitor/SnmpMonitor/NetworkTopology";
+import NetworkDevice from "../../../Models/DatabaseModels/NetworkDevice";
 
 /*
  * Issue #3435 — what the "Add to Monitoring" dialog actually opens with.
@@ -25,6 +26,12 @@ import {
  * initialValues object is type-safe, render-safe, and puts the operator back
  * to retyping what OneUptime already discovered.
  *
+ * Every device the dialog creates is probe-polled: there is no monitoring
+ * method to choose, the probe is required for a phone exactly as for a
+ * switch, and the SNMP step is optional for both. The cases below that used
+ * to split on "will this device be polled?" now assert that no such split
+ * exists.
+ *
  * The form itself is configuration passed as props, so ModelFormModal is
  * mocked to capture them and the capture is asserted directly — the same
  * approach DiscoveryScanWizardValidation.test.tsx uses for the Discovery
@@ -35,11 +42,18 @@ type CapturedModalProps = {
   title: string;
   description: string;
   initialValues: Record<string, unknown>;
+  onBeforeCreate?:
+    | ((
+        item: NetworkDevice,
+        miscDataProps: Record<string, unknown>,
+      ) => Promise<NetworkDevice>)
+    | undefined;
   formProps: {
-    steps: Array<{ id: string; title: string }>;
+    steps: Array<{ id: string; title: string; showIf?: unknown }>;
     fields: Array<{
       field: Record<string, boolean>;
       required?: boolean | undefined;
+      stepId?: string | undefined;
       dropdownOptions?: Array<{ label: string; value: string }> | undefined;
     }>;
   };
@@ -128,12 +142,26 @@ const SECOND_SWITCH_NODE: NetworkTopologyNode = {
   status: "up",
 };
 
+/*
+ * Carries the role stamp the topology builder puts on a node now that roles
+ * are per-project rows: `roleId` is the project's row for the classified role,
+ * and it is what the form can actually preselect - the role is a relation, and
+ * a form cannot resolve a key to a row.
+ */
+const PHONE_ROLE_ID: string = "b7a1a0f6-3a4b-4a0e-9c3f-4f1f7f2a91cd";
+
+const SWITCH_ROLE_ID: string = "0c2d5b41-9f22-4a3e-8f61-2d7c6a4e8b03";
+
 const PHONE_NODE: NetworkTopologyNode = {
   id: "unmanaged:sep6026aaf2b46b",
   name: "SEP6026AAF2B46B",
   isManaged: false,
   kind: "unmanaged",
   role: "phone",
+  roleKey: "phone",
+  roleLabel: "IP phone",
+  roleId: PHONE_ROLE_ID,
+  isSnmpWalkableRole: false,
   status: "unknown",
   deviceModel: "Cisco IP Phone 8811",
   ipAddress: "10.0.12.41",
@@ -227,17 +255,58 @@ describe("the Add to Monitoring dialog", () => {
   test("opens on the role the map classified the device as", async () => {
     const props: CapturedModalProps = await openDialog();
 
-    expect(props.initialValues["deviceRole"]).toBe("phone");
+    /*
+     * The row's id, not the classifier's key: the role is a relation to the
+     * project's own NetworkDeviceRole table, so this is what the picker binds
+     * to and what a rename or a custom role travels through.
+     */
+    expect(props.initialValues["networkDeviceRole"]).toBe(PHONE_ROLE_ID);
   });
 
   /*
-   * A phone is never SNMP-walkable, so opening on SNMP would create a device
-   * that queues a walk it can only fail and then reads "pending" forever.
+   * There is no monitoring-method question any more. A phone is never
+   * SNMP-walkable, but it is pingable — and pinging is all a probe-polled
+   * device needs to have a status — so the dialog asks nothing and writes
+   * Probe on the way out. ModelForm sends only the fields it renders, which
+   * is why the method travels through onBeforeCreate rather than
+   * initialValues: a seeded value with no field behind it would never reach
+   * the server.
    */
-  test("opens a leaf device on monitor-backed rather than SNMP", async () => {
+  test("asks no monitoring-method question and writes Probe on the way out", async () => {
     const props: CapturedModalProps = await openDialog();
 
-    expect(props.initialValues["monitoringMethod"]).toBe("Monitor");
+    expect(fieldFor(props, "monitoringMethod")).toBeUndefined();
+    expect(props.initialValues["monitoringMethod"]).toBeUndefined();
+    expect(props.onBeforeCreate).toBeDefined();
+
+    const device: NetworkDevice = await props.onBeforeCreate!(
+      new NetworkDevice(),
+      {},
+    );
+
+    expect(device.monitoringMethod).toBe("Probe");
+  });
+
+  /*
+   * And the same for an infrastructure peer: the method is not a function of
+   * the role, so a switch and a phone leave the dialog identically.
+   */
+  test("writes Probe for a walkable peer too", async () => {
+    const props: CapturedModalProps = await openDialog({
+      ...PHONE_NODE,
+      role: "switch",
+      roleKey: "switch",
+      roleLabel: "Switch",
+      roleId: SWITCH_ROLE_ID,
+      isSnmpWalkableRole: true,
+    });
+
+    const device: NetworkDevice = await props.onBeforeCreate!(
+      new NetworkDevice(),
+      {},
+    );
+
+    expect(device.monitoringMethod).toBe("Probe");
   });
 
   /*
@@ -290,24 +359,42 @@ describe("the Add to Monitoring dialog", () => {
   });
 
   /*
-   * The probe is only offered to a device something will actually poll —
-   * a monitor-backed device has no poller, and the field is hidden on that
-   * branch anyway.
+   * The probe is inherited for EVERY device. It used to be withheld from a
+   * leaf device, which opened on a monitor-backed branch with the probe
+   * field hidden; a phone is as probe-polled as a switch now, so the probe
+   * its neighbours agree on is the right head start for both. The phone
+   * fixture carries the handset's isSnmpWalkableRole: false, which is
+   * exactly the case the seed used to be withheld from.
    */
-  test("inherits a probe for a device that will be polled", async () => {
+  test("inherits a probe for a leaf device", async () => {
+    const props: CapturedModalProps = await openDialog();
+
+    expect(props.initialValues["probe"]).toBe("probe-a");
+  });
+
+  test("inherits a probe for a walkable device", async () => {
     const props: CapturedModalProps = await openDialog({
       ...PHONE_NODE,
       role: "switch",
+      roleKey: "switch",
+      roleLabel: "Switch",
+      roleId: SWITCH_ROLE_ID,
+      isSnmpWalkableRole: true,
     });
 
-    expect(props.initialValues["monitoringMethod"]).toBe("SNMP");
     expect(props.initialValues["probe"]).toBe("probe-a");
   });
 
-  test("does not hand a probe to a device nothing will poll", async () => {
+  /*
+   * Required for a phone exactly as for a switch: a probe-polled device with
+   * no probe is claimed by nothing and never polls, which is the "Pending
+   * forever" this flow exists to end. The server does not insist, so the
+   * form does.
+   */
+  test("requires a probe for a leaf device", async () => {
     const props: CapturedModalProps = await openDialog();
 
-    expect(props.initialValues["probe"]).toBeUndefined();
+    expect(fieldFor(props, "probe")?.required).toBe(true);
   });
 
   /*
@@ -331,16 +418,16 @@ describe("the Add to Monitoring dialog", () => {
   });
 
   /*
-   * The create form on the Devices list requires a monitor for a
-   * monitor-backed device. Here it must not: an operator adopting a phone
-   * from the map has no Ping monitor for it yet, and the server has always
-   * allowed the two to be bound later — the same contract the discovery
-   * import relies on.
+   * No Monitor binding field at all. The binding is the override for gear a
+   * probe cannot reach, chosen on a device's Settings page; a neighbour the
+   * probe just heard about from the switch beside it is, by construction,
+   * reachable — so the dialog does not offer a field whose only honest value
+   * here is "empty".
    */
-  test("does not demand a monitor that does not exist yet", async () => {
+  test("has no monitor binding field", async () => {
     const props: CapturedModalProps = await openDialog();
 
-    expect(fieldFor(props, "monitor")?.required).toBe(false);
+    expect(fieldFor(props, "monitor")).toBeUndefined();
   });
 
   test("still demands the two things a device cannot exist without", async () => {
@@ -384,18 +471,62 @@ describe("the Add to Monitoring dialog", () => {
     ]);
   });
 
-  test("walks the operator through the same steps the Devices form does", async () => {
+  test("walks the operator through Device Details, Probe & Site and SNMP", async () => {
     const props: CapturedModalProps = await openDialog();
 
     expect(
       props.formProps.steps.map((step: { id: string }) => {
         return step.id;
       }),
-    ).toEqual([
-      "monitoring-method",
-      "device-details",
-      "probe-and-site",
-      "snmp",
-    ]);
+    ).toEqual(["device-details", "probe-and-site", "snmp"]);
+  });
+
+  /*
+   * The SNMP step is walked through by every device, a phone included. It
+   * used to be hidden wholesale for a leaf device (nothing polled it, so
+   * nothing could use a credential); now the probe walks whatever it has
+   * credentials for, and leaving the step empty is the "ping only" answer.
+   */
+  test("shows the SNMP step to a leaf device, unconditionally", async () => {
+    const props: CapturedModalProps = await openDialog();
+
+    const snmpStep: { id: string; showIf?: unknown } | undefined =
+      props.formProps.steps.find((step: { id: string }) => {
+        return step.id === "snmp";
+      });
+
+    expect(snmpStep).toBeDefined();
+    expect(snmpStep?.showIf).toBeUndefined();
+    expect(fieldFor(props, "snmpVersion")).toBeDefined();
+    expect(fieldFor(props, "snmpCommunityString")?.required).toBe(false);
+  });
+
+  /*
+   * Every step the wizard declares is claimed by a field, and every field
+   * names a declared step — the two silent failures NetworkFormStepsInvariants
+   * pins against the source, asserted here against the props the form is
+   * actually handed.
+   */
+  test("every field lands on a step the wizard declares, and no step is empty", async () => {
+    const props: CapturedModalProps = await openDialog();
+
+    const declared: Array<string> = props.formProps.steps.map(
+      (step: { id: string }) => {
+        return step.id;
+      },
+    );
+    const used: Array<string> = props.formProps.fields.map(
+      (field: { stepId?: string | undefined }) => {
+        return field.stepId || "";
+      },
+    );
+
+    for (const stepId of used) {
+      expect(declared).toContain(stepId);
+    }
+
+    for (const stepId of declared) {
+      expect(used).toContain(stepId);
+    }
   });
 });

package/Tests/App/Dashboard/AskAiSuggestedPrompts.test.ts

@@ -0,0 +1,279 @@
+import { describe, expect, test } from "@jest/globals";
+import PageContextUtil, {
+  DashboardPageContext,
+  SuggestedQuestion,
+} from "../../../../App/FeatureSet/Dashboard/src/Components/AIChat/PageContext";
+import { buildPageContextSection } from "../../../Server/Utils/AI/Chat/ObservabilityChatPrompt";
+import { QueryAlertsTool } from "../../../Server/Utils/AI/Toolbox/AlertTools";
+import AIChatPageContextType, {
+  AIChatPageContextHelper,
+} from "../../../Types/AI/AIChatPageContext";
+import IconProp from "../../../Types/Icon/IconProp";
+import { JSONObject } from "../../../Types/JSON";
+
+/*
+ * Ask AI renders the suggested prompt cards in PageContextUtil.getSuggestions
+ * as first-class buttons: one click sends that exact question. Nothing in the
+ * type system ties a card to a capability the model actually has, and the two
+ * halves live in different packages — the deck in the dashboard bundle, the
+ * per-page capability claim the server injects into the system prompt in
+ * Common/Server.
+ *
+ * Issue #3552 is what that gap looks like in production. The incidents list
+ * offered "Active incidents — Which incidents are currently active or
+ * unresolved?", while the page guidance summarised the very tool that answers
+ * it as "query_incidents (recent incidents, or one by incidentId)". The tool
+ * itself had always supported state="active"; the prompt described it as
+ * narrower than it was, and the model dutifully paraphrased the prompt back at
+ * the user: it had no way to list active incidents and needed an incidentId.
+ * The product shipped a button that made the assistant deny the feature.
+ *
+ * These tests are the structural guard for that whole class of bug: a card the
+ * model has not been told it can answer.
+ */
+
+// Valid-shaped ids so entity contexts route through the entity guidance.
+const ENTITY_ID: string = "0f10509d-6656-4a08-b957-235fd4e8c52e";
+const TRACE_ID: string = "4bf92f3577b34da6a3ce929d0e0e4736";
+
+/*
+ * Tool names are the one thing every page guidance must carry — snake_case
+ * identifiers like query_incidents or log_histogram. Guidance that names no
+ * tool tells the model nothing it can act on.
+ */
+const TOOL_NAME_REGEX: RegExp = /\b[a-z]+(?:_[a-z]+)+\b/;
+
+// A card's question is either a question or a complete instruction.
+const COMPLETE_SENTENCE_REGEX: RegExp = /^[A-Z].*[?.]$/;
+
+// Card matchers, as named constants so they read as intent rather than syntax.
+const MENTIONS_AN_INCIDENT: RegExp = /incident/i;
+const ASKS_FOR_UNFINISHED_WORK: RegExp = /\b(active|unresolved|open)\b/i;
+const MENTIONS_A_SOURCE: RegExp = /monitor|source/i;
+
+/*
+ * The card title is rendered on a single line in a half-width grid cell, so it
+ * has to stay short — this is a layout constraint, not a copy preference.
+ */
+const MAX_TITLE_LENGTH: number = 32;
+
+const ALL_PAGE_CONTEXT_TYPES: Array<AIChatPageContextType> = Object.values(
+  AIChatPageContextType,
+);
+
+function buildContext(type: AIChatPageContextType): DashboardPageContext {
+  const isEntity: boolean = AIChatPageContextHelper.isEntityType(type);
+
+  return {
+    type: type,
+    noun: "thing",
+    chipLabel: "Thing",
+    icon: IconProp.Alert,
+    isEntity: isEntity,
+    ...(isEntity
+      ? {
+          entityId: type === AIChatPageContextType.Trace ? TRACE_ID : ENTITY_ID,
+        }
+      : {}),
+  };
+}
+
+function getDeck(type: AIChatPageContextType): Array<SuggestedQuestion> {
+  return PageContextUtil.getSuggestions(buildContext(type));
+}
+
+function getGuidance(type: AIChatPageContextType): string {
+  return buildPageContextSection(buildContext(type));
+}
+
+const TYPES_WITH_A_DECK: Array<AIChatPageContextType> =
+  ALL_PAGE_CONTEXT_TYPES.filter((type: AIChatPageContextType): boolean => {
+    return getDeck(type).length > 0;
+  });
+
+// test.each rows have to be tuples, so wrap each type in a one-column row.
+const DECK_ROWS: Array<[AIChatPageContextType]> = TYPES_WITH_A_DECK.map(
+  (type: AIChatPageContextType): [AIChatPageContextType] => {
+    return [type];
+  },
+);
+
+describe("Ask AI suggested prompts are backed by capabilities the model is told about", () => {
+  /*
+   * The exact pairing #3552 broke, asserted as one invariant because that is
+   * what it is: the card is only honest if the guidance names the argument
+   * that answers it. Either half alone passes happily while the product lies
+   * to the user.
+   *
+   * Fails on the pre-fix prompt, which said "recent incidents, or one by
+   * incidentId" and never mentioned state="active".
+   */
+  test('the incidents list offers an "active incidents" card AND its guidance names state="active"', () => {
+    const deck: Array<SuggestedQuestion> = getDeck(
+      AIChatPageContextType.IncidentsList,
+    );
+
+    const activeIncidentsCard: SuggestedQuestion | undefined = deck.find(
+      (suggestion: SuggestedQuestion): boolean => {
+        return (
+          MENTIONS_AN_INCIDENT.test(suggestion.question) &&
+          ASKS_FOR_UNFINISHED_WORK.test(suggestion.question)
+        );
+      },
+    );
+
+    expect(activeIncidentsCard).toBeDefined();
+
+    const guidance: string = getGuidance(AIChatPageContextType.IncidentsList);
+
+    expect(guidance).toContain("query_incidents");
+    expect(guidance).toContain('state="active"');
+
+    /*
+     * The exact regression: describing query_incidents as only "recent
+     * incidents, or one by incidentId" is the sentence the model paraphrased
+     * back as "I have no tool for that, give me an incidentId".
+     */
+    expect(guidance).not.toContain("recent incidents, or one by incidentId");
+  });
+
+  /*
+   * Three list pages lead with a "what is broken RIGHT NOW" card, and each
+   * needs a different argument to answer it. The narrow-capability-claim bug
+   * was identical on all three, so pin all three rather than only the one the
+   * issue happened to be filed against.
+   *
+   * All three rows fail on the pre-fix prompt, which named the tool but none
+   * of these arguments.
+   */
+  test.each<[AIChatPageContextType, RegExp, string]>([
+    [
+      AIChatPageContextType.IncidentsList,
+      /\b(active|unresolved)\b/i,
+      'state="active"',
+    ],
+    [AIChatPageContextType.AlertsList, /\b(open|active)\b/i, 'state="active"'],
+    [
+      AIChatPageContextType.MonitorsList,
+      /not operational|right now/i,
+      "problemsOnly=true",
+    ],
+  ])(
+    "%s: the guidance names the argument its right-now card depends on",
+    (
+      type: AIChatPageContextType,
+      cardQuestion: RegExp,
+      affordance: string,
+    ): void => {
+      const deck: Array<SuggestedQuestion> = getDeck(type);
+
+      const rightNowCard: SuggestedQuestion | undefined = deck.find(
+        (suggestion: SuggestedQuestion): boolean => {
+          return cardQuestion.test(suggestion.question);
+        },
+      );
+
+      expect(rightNowCard).toBeDefined();
+      expect(getGuidance(type)).toContain(affordance);
+    },
+  );
+
+  /*
+   * Every page that offers cards must also give the model page-scoped
+   * guidance. A page with a deck and an empty section is the same defect as
+   * #3552 in a different place: the user is invited to ask, and the model is
+   * told nothing about where the answer lives. Guard — both halves have always
+   * been populated for every type, and this keeps the next page from shipping
+   * with only one of them.
+   */
+  test("every page context type is either silent or offers both cards and guidance", () => {
+    expect(TYPES_WITH_A_DECK.length).toBeGreaterThan(0);
+
+    const typesMissingGuidance: Array<AIChatPageContextType> =
+      TYPES_WITH_A_DECK.filter((type: AIChatPageContextType): boolean => {
+        return getGuidance(type).trim().length === 0;
+      });
+
+    expect(typesMissingGuidance).toEqual([]);
+  });
+
+  /*
+   * Guidance that names no tool is guidance the model cannot act on — it can
+   * only fall back to "I don't have a way to do that", which is exactly the
+   * user-visible symptom of #3552. Guard.
+   */
+  test.each<[AIChatPageContextType]>(DECK_ROWS)(
+    "%s guidance names at least one tool",
+    (type: AIChatPageContextType): void => {
+      expect(getGuidance(type)).toMatch(TOOL_NAME_REGEX);
+    },
+  );
+
+  /*
+   * Card hygiene. The question string is sent verbatim to the model when the
+   * card is clicked, so a blank or fragmentary one is a broken button; the
+   * title is the card's only label and ChatHomeView keys the rendered list by
+   * it, so duplicates within a deck collide as React keys. Guard.
+   */
+  test.each<[AIChatPageContextType]>(DECK_ROWS)(
+    "%s cards are well formed and uniquely titled",
+    (type: AIChatPageContextType): void => {
+      const deck: Array<SuggestedQuestion> = getDeck(type);
+
+      for (const suggestion of deck) {
+        expect(suggestion.title.trim().length).toBeGreaterThan(0);
+        expect(suggestion.title.length).toBeLessThanOrEqual(MAX_TITLE_LENGTH);
+        expect(suggestion.question.trim()).toMatch(COMPLETE_SENTENCE_REGEX);
+      }
+
+      const titles: Array<string> = deck.map(
+        (suggestion: SuggestedQuestion): string => {
+          return suggestion.title;
+        },
+      );
+
+      expect(new Set(titles).size).toBe(titles.length);
+    },
+  );
+
+  /*
+   * The alerts deck's "Noisiest source" card asks which monitor generates the
+   * most alerts. Answering it needs the originating monitor on every alert
+   * row — without it the model can only guess a source from alert titles, or
+   * say it cannot tell. The card is only honest once query_alerts both returns
+   * that column and says so in its description, since the description is what
+   * the model reads when deciding whether the question is answerable.
+   *
+   * Fails on the pre-fix tool, whose description never mentioned the monitor.
+   */
+  test('the alerts deck\'s "noisiest source" card is backed by monitor data in query_alerts', () => {
+    const deck: Array<SuggestedQuestion> = getDeck(
+      AIChatPageContextType.AlertsList,
+    );
+
+    const noisiestSourceCard: SuggestedQuestion | undefined = deck.find(
+      (suggestion: SuggestedQuestion): boolean => {
+        return MENTIONS_A_SOURCE.test(suggestion.question);
+      },
+    );
+
+    expect(noisiestSourceCard).toBeDefined();
+
+    const description: string = QueryAlertsTool.description;
+
+    expect(description).toMatch(/\bmonitor\b/i);
+
+    /*
+     * The monitor has to be something the tool RETURNS, not something the
+     * caller filters by — that distinction is what makes the card answerable.
+     * Asserted structurally rather than by word order, so a copy edit to the
+     * description does not fail this test.
+     */
+    const properties: JSONObject =
+      (QueryAlertsTool.inputSchema["properties"] as JSONObject | undefined) ||
+      {};
+
+    expect(properties["monitor"]).toBeUndefined();
+    expect(properties["monitorId"]).toBeUndefined();
+  });
+});

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

@@ -20,13 +20,23 @@ import * as React from "react";
 import getJestMockFunction, { MockFunction } from "../../MockType";
 
 /*
- * Drag-to-zoom on a dashboard chart widget is the "investigate this
- * spike" entry point: selecting a window must narrow THIS widget only
- * (never the dashboard-wide range), refetch for the narrowed window, and
- * offer a way back (Reset) and a way deeper (Open in Explorer, carrying
- * the zoomed window). Edit mode must not zoom — the drag gesture belongs
- * to widget move/resize there, and series pivots would navigate away from
- * unsaved dashboard changes.
+ * The chart widget's STANDALONE fallback: what drag-to-zoom does when the
+ * host hands down no onDashboardTimeRangeSelect — the edit-mode settings
+ * preview, and any future surface that mounts the widget without owning a
+ * time range. Selecting a window narrows THIS widget, refetches for the
+ * narrowed window, and offers a way back (Reset) and a way deeper (Open in
+ * Explorer, carrying the zoomed window).
+ *
+ * On a real dashboard the shell DOES take the drag and the whole board
+ * retimes (issue #3530) — that contract lives in
+ * DashboardWideChartZoom.test.tsx. Both paths are pinned because the
+ * widget picks between them purely on whether the callback prop is
+ * present, and a host that forgets to pass it should degrade to this
+ * rather than lose the gesture.
+ *
+ * Edit mode must not zoom either way — the drag gesture belongs to widget
+ * move/resize there, and series pivots would navigate away from unsaved
+ * dashboard changes.
  */
 
 const fetchResultsMock: MockFunction = getJestMockFunction();
@@ -215,7 +225,24 @@ afterEach(() => {
   cleanup();
 });
 
-describe("dashboard chart widget drag-to-zoom", () => {
+describe("dashboard chart widget drag-to-zoom (standalone fallback)", () => {
+  test("the fallback is what runs when the host offers no dashboard-wide zoom", async () => {
+    renderWidget();
+
+    await waitFor(() => {
+      expect(screen.getByTestId("metric-charts")).toBeInTheDocument();
+    });
+
+    /*
+     * Guards the branch this whole suite depends on: these props are the
+     * switch between narrowing this widget and retiming the board, and
+     * buildBaseProps deliberately leaves them off.
+     */
+    const baseProps: DashboardBaseComponentProps = buildBaseProps();
+    expect(baseProps.onDashboardTimeRangeSelect).toBeUndefined();
+    expect(baseProps.onDashboardTimeRangeReset).toBeUndefined();
+  });
+
   test("drag-selecting a window refetches THIS widget for that window and shows the zoom bar", async () => {
     renderWidget();