@oneuptime/common 12.0.32 → 12.0.33

package/Tests/Server/Services/UserNotificationSettingWorkspaceChannels.test.ts

@@ -5,16 +5,19 @@ import WorkspaceUserNotificationService from "../../../Server/Services/Workspace
 import ProjectCallSMSConfigService from "../../../Server/Services/ProjectCallSMSConfigService";
 import MailService from "../../../Server/Services/MailService";
 import UserEmailService from "../../../Server/Services/UserEmailService";
+import UserNotificationEmailRollupItemService from "../../../Server/Services/UserNotificationEmailRollupItemService";
 import logger from "../../../Server/Utils/Logger";
 import UserNotificationSetting from "../../../Models/DatabaseModels/UserNotificationSetting";
 import UserSlack from "../../../Models/DatabaseModels/UserSlack";
 import UserMicrosoftTeams from "../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserEmail from "../../../Models/DatabaseModels/UserEmail";
+import UserNotificationEmailRollupItem from "../../../Models/DatabaseModels/UserNotificationEmailRollupItem";
 import { CallRequestMessage } from "../../../Types/Call/CallRequest";
 import { EmailEnvelope } from "../../../Types/Email/EmailMessage";
 import EmailTemplateType from "../../../Types/Email/EmailTemplateType";
 import NotificationSettingEventType from "../../../Types/NotificationSetting/NotificationSettingEventType";
 import ObjectID from "../../../Types/ObjectID";
+import PositiveNumber from "../../../Types/PositiveNumber";
 import PushNotificationMessage from "../../../Types/PushNotification/PushNotificationMessage";
 import { SMSMessage } from "../../../Types/SMS/SMS";
 import { WhatsAppMessagePayload } from "../../../Types/WhatsApp/WhatsAppMessage";
@@ -150,6 +153,23 @@ describe("UserNotificationSettingService.sendUserNotification - workspace channe
       .spyOn(MailService, "sendMail")
       .mockResolvedValue(undefined as never);
 
+    /*
+     * The email branch now runs through EmailRollupWriter, which counts this
+     * address's recent owner emails and writes a ledger row before sending.
+     * Both are stubbed here on purpose rather than left unmocked: an unmocked
+     * countBy rejects with no database, the writer's fail-open catch swallows
+     * that, and every email assertion in this suite would then be exercising
+     * the failure path. "Below the burst threshold nothing changed" has to be
+     * pinned deliberately, not by accident.
+     */
+    jest
+      .spyOn(UserNotificationEmailRollupItemService, "countBy")
+      .mockResolvedValue(new PositiveNumber(0) as never);
+
+    jest
+      .spyOn(UserNotificationEmailRollupItemService, "create")
+      .mockResolvedValue(new UserNotificationEmailRollupItem() as never);
+
     findSlacks = jest.spyOn(UserSlackService, "findBy").mockResolvedValue([
       {
         id: new ObjectID("44444444-4444-4444-8444-444444444444"),
@@ -431,7 +451,88 @@ describe("UserNotificationSettingService.sendUserNotification - workspace channe
 
   /*
    * ----------------------------------------------------------------------- *
-   * (D) Failure isolation.
+   * (D) The email hand-off is unchanged by the rollup seam.
+   * -----------------------------------------------------------------------
+   */
+
+  describe("the email hand-off", () => {
+    /*
+     * Owner emails now pass through EmailRollupWriter on their way to
+     * MailService. Below the burst threshold that has to be invisible, and
+     * "invisible" means these two exact arguments - not merely an email that
+     * arrives. The second argument is the correlation-id bag every downstream
+     * log line joins on, so a field silently dropped in the hand-off would
+     * detach incident emails from their incident with nothing failing.
+     */
+    test("MailService receives the identical envelope and correlation-id options it received before rollup existed", async () => {
+      findSettings.mockResolvedValue(
+        settingsRow({ alertByEmail: true }) as never,
+      );
+
+      await UserNotificationSettingService.sendUserNotification(
+        notificationData(),
+      );
+
+      expect(sendMail).toHaveBeenCalledTimes(1);
+
+      expect(sendMail.mock.calls[0]?.[0]).toEqual({
+        subject: "Incident created: Checkout is down",
+        templateType: EmailTemplateType.BlankTemplate,
+        vars: {},
+        toEmail: "user@example.com",
+      });
+
+      expect(sendMail.mock.calls[0]?.[1]).toEqual({
+        projectId: PROJECT_ID,
+        incidentId: INCIDENT_ID,
+        alertId: undefined,
+        alertEpisodeId: undefined,
+        incidentEpisodeId: undefined,
+        monitorId: undefined,
+        scheduledMaintenanceId: undefined,
+        statusPageId: undefined,
+        statusPageAnnouncementId: undefined,
+        userId: USER_ID,
+        teamId: undefined,
+        onCallPolicyId: undefined,
+        onCallPolicyEscalationRuleId: undefined,
+        onCallDutyPolicyExecutionLogTimelineId: undefined,
+        onCallScheduleId: undefined,
+      });
+
+      /*
+       * toEqual treats an explicitly-undefined property as absent, so the key
+       * set is pinned separately - otherwise the hand-off could quietly stop
+       * forwarding a field and this test would still pass.
+       */
+      const optionKeys: Array<string> = Object.keys(
+        sendMail.mock.calls[0]?.[1] as Record<string, unknown>,
+      ).sort();
+      expect(optionKeys).toEqual(
+        [
+          "alertEpisodeId",
+          "alertId",
+          "incidentEpisodeId",
+          "incidentId",
+          "monitorId",
+          "onCallDutyPolicyExecutionLogTimelineId",
+          "onCallPolicyEscalationRuleId",
+          "onCallPolicyId",
+          "onCallScheduleId",
+          "projectId",
+          "scheduledMaintenanceId",
+          "statusPageAnnouncementId",
+          "statusPageId",
+          "teamId",
+          "userId",
+        ].sort(),
+      );
+    });
+  });
+
+  /*
+   * ----------------------------------------------------------------------- *
+   * (E) Failure isolation.
    * -----------------------------------------------------------------------
    */
 

package/Tests/Server/Types/Database/Permissions/DashboardAccessPermission.test.ts

@@ -0,0 +1,321 @@
+import DatabaseRequestType from "../../../../../Server/Types/BaseDatabase/DatabaseRequestType";
+import OwnedScopePermission from "../../../../../Server/Types/Database/Permissions/OwnedScopePermission";
+import TablePermission from "../../../../../Server/Types/Database/Permissions/TablePermission";
+import Dashboard from "../../../../../Models/DatabaseModels/Dashboard";
+import DatabaseCommonInteractionProps from "../../../../../Types/BaseDatabase/DatabaseCommonInteractionProps";
+import PermissionScope from "../../../../../Types/Database/AccessControl/PermissionScope";
+import ObjectID from "../../../../../Types/ObjectID";
+import Permission, {
+  UserPermission,
+  UserTenantAccessPermission,
+} from "../../../../../Types/Permission";
+import { FindOperator } from "typeorm";
+
+/*
+ * github.com/OneUptime/oneuptime/issues/3550 reported that a user holding only
+ * the read-only `Viewer` and `MonitorViewer` roles could open a dashboard they
+ * were not an owner of AND save changes to it.
+ *
+ * These tests pin down what the server actually does, because the two halves of
+ * that report have different answers:
+ *
+ *   - Reading is allowed, and is meant to be. `Viewer` is documented as
+ *     "read-only access across all project resources", and the reported team
+ *     granted it at scope "All resources in project". Narrowing visibility to
+ *     the resources somebody owns is what the `Owned` scope on the permission
+ *     row is for - the last two tests here are the proof that it reaches
+ *     dashboards.
+ *
+ *   - Writing was never allowed. Dashboard's update ACL is
+ *     [ProjectOwner, ProjectAdmin, EditDashboard], so the PUT the editor
+ *     eventually sends is refused. What was broken lived entirely in the UI,
+ *     which offered the whole editing surface to a reader and only surfaced the
+ *     refusal after the work was done (see
+ *     Common/Tests/App/Dashboard/DashboardEditPermissions.test.tsx). These
+ *     cases stand guard over the ACL that makes that refusal happen.
+ */
+describe("Dashboard access control (issue #3550)", () => {
+  const projectId: ObjectID = ObjectID.generate();
+  const userId: ObjectID = ObjectID.generate();
+
+  type MakePropsFunction = (
+    permissions: Array<Permission>,
+    scope?: PermissionScope | undefined,
+  ) => DatabaseCommonInteractionProps;
+
+  /*
+   * The permission set a member of the reported team actually carries:
+   * whatever their team grants, plus the implicit grants every signed-in
+   * project member gets (see UserPermissionUtil).
+   */
+  const makeProps: MakePropsFunction = (
+    permissions: Array<Permission>,
+    scope?: PermissionScope | undefined,
+  ): DatabaseCommonInteractionProps => {
+    const userPermissions: Array<UserPermission> = permissions.map(
+      (permission: Permission) => {
+        return {
+          _type: "UserPermission" as const,
+          permission: permission,
+          labelIds: [],
+          isBlockPermission: false,
+          ...(scope ? { scope: scope } : {}),
+        };
+      },
+    );
+
+    // Implicit grants - never scoped, never stored on a TeamPermission row.
+    for (const implicitPermission of [
+      Permission.CurrentUser,
+      Permission.ProjectUser,
+      Permission.UnAuthorizedSsoUser,
+    ]) {
+      userPermissions.push({
+        _type: "UserPermission",
+        permission: implicitPermission,
+        labelIds: [],
+        isBlockPermission: false,
+      });
+    }
+
+    const tenantPermission: UserTenantAccessPermission = {
+      projectId,
+      _type: "UserTenantAccessPermission",
+      permissions: userPermissions,
+    };
+
+    return {
+      userId,
+      tenantId: projectId,
+      userTenantAccessPermission: {
+        [projectId.toString()]: tenantPermission,
+      },
+    };
+  };
+
+  type CheckFunction = (
+    permissions: Array<Permission>,
+    type: DatabaseRequestType,
+  ) => Error | null;
+
+  const check: CheckFunction = (
+    permissions: Array<Permission>,
+    type: DatabaseRequestType,
+  ): Error | null => {
+    try {
+      TablePermission.checkTableLevelPermissions(
+        Dashboard,
+        makeProps(permissions),
+        type,
+      );
+    } catch (err) {
+      return err as Error;
+    }
+
+    return null;
+  };
+
+  const readOnlyRoles: Array<Permission> = [
+    Permission.Viewer,
+    Permission.MonitorViewer,
+  ];
+
+  describe("the roles from the report", () => {
+    test("Viewer + Monitor Viewer may READ a dashboard", () => {
+      expect(check(readOnlyRoles, DatabaseRequestType.Read)).toBeNull();
+    });
+
+    test("Viewer + Monitor Viewer may NOT update a dashboard", () => {
+      const error: Error | null = check(
+        readOnlyRoles,
+        DatabaseRequestType.Update,
+      );
+
+      expect(error).not.toBeNull();
+      expect(error?.message).toContain(
+        "You do not have permissions to update Dashboard",
+      );
+      /*
+       * The message names the permissions that would work, in their human
+       * titles. The UI gate reproduces this same sentence so the two do not
+       * read like different products.
+       */
+      expect(error?.message).toContain("Edit Dashboard");
+      expect(error?.message).toContain("Project Admin");
+      expect(error?.message).toContain("Project Owner");
+    });
+
+    test("Viewer + Monitor Viewer may NOT create a dashboard", () => {
+      const error: Error | null = check(
+        readOnlyRoles,
+        DatabaseRequestType.Create,
+      );
+
+      expect(error).not.toBeNull();
+      expect(error?.message).toContain(
+        "You do not have permissions to create Dashboard",
+      );
+    });
+
+    test("Viewer + Monitor Viewer may NOT delete a dashboard", () => {
+      const error: Error | null = check(
+        readOnlyRoles,
+        DatabaseRequestType.Delete,
+      );
+
+      expect(error).not.toBeNull();
+      expect(error?.message).toContain(
+        "You do not have permissions to delete Dashboard",
+      );
+    });
+
+    /*
+     * The project-wide Viewer role is read-only by definition, so it must not
+     * pick up write access to a dashboard by any route - not through the
+     * granular Dashboard permissions and not through the operational
+     * wildcards, neither of which it holds.
+     */
+    test("no combination of the reported roles grants a write", () => {
+      for (const type of [
+        DatabaseRequestType.Create,
+        DatabaseRequestType.Update,
+        DatabaseRequestType.Delete,
+      ]) {
+        expect(check([Permission.Viewer], type)).not.toBeNull();
+        expect(check([Permission.MonitorViewer], type)).not.toBeNull();
+        expect(check(readOnlyRoles, type)).not.toBeNull();
+      }
+    });
+  });
+
+  describe("the permissions that DO grant a write", () => {
+    test("Edit Dashboard allows an update", () => {
+      expect(
+        check([Permission.EditDashboard], DatabaseRequestType.Update),
+      ).toBeNull();
+    });
+
+    test("Project Admin allows an update", () => {
+      expect(
+        check([Permission.ProjectAdmin], DatabaseRequestType.Update),
+      ).toBeNull();
+    });
+
+    /*
+     * Dashboard is @OperationalResource, so the wildcard covers it even though
+     * it is not enumerated in the model's ACL. The UI gate has to know this
+     * too, or it would lock the editor for somebody the API would let through.
+     */
+    test("Edit All Operational Resources allows an update", () => {
+      expect(
+        check(
+          [Permission.EditAllOperationalResources],
+          DatabaseRequestType.Update,
+        ),
+      ).toBeNull();
+    });
+
+    test("Read All Operational Resources does NOT allow an update", () => {
+      expect(
+        check(
+          [Permission.ReadAllOperationalResources],
+          DatabaseRequestType.Update,
+        ),
+      ).not.toBeNull();
+    });
+  });
+
+  /*
+   * The half of the report that is a configuration answer rather than a bug:
+   * "a dashboard with no assigned Owner should not be visible to arbitrary
+   * team members". That is exactly what scope `Owned` does, and Dashboard is
+   * registered in the owner-table registry so it resolves through
+   * DashboardOwnerUser / DashboardOwnerTeam.
+   */
+  describe("restricting visibility to owners via the Owned scope", () => {
+    const ownedDashboardId: ObjectID = ObjectID.generate();
+
+    afterEach(() => {
+      jest.restoreAllMocks();
+    });
+
+    /*
+     * The ids end up as bound parameters on a Raw operator, so the values are
+     * read off objectLiteralParameters rather than off `value`.
+     */
+    type BoundValuesFunction = (operator: FindOperator<any>) => Array<string>;
+
+    const boundValues: BoundValuesFunction = (
+      operator: FindOperator<any>,
+    ): Array<string> => {
+      /*
+       * `in` binds the whole id list to a single parameter, `equalTo` binds one
+       * value per parameter - flatten so both shapes read the same here.
+       */
+      return Object.values(
+        (operator.objectLiteralParameters || {}) as Record<string, unknown>,
+      ).flatMap((value: unknown) => {
+        return Array.isArray(value) ? value.map(String) : [String(value)];
+      });
+    };
+
+    test("an Owned-scoped Viewer only sees dashboards they own", async () => {
+      jest
+        .spyOn(OwnedScopePermission as any, "getAllowedResourceIds")
+        .mockResolvedValue([ownedDashboardId]);
+
+      const query: any = await OwnedScopePermission.addOwnedScopeToQuery(
+        Dashboard,
+        { projectId } as any,
+        makeProps([Permission.Viewer], PermissionScope.Owned),
+        DatabaseRequestType.Read,
+      );
+
+      expect(query._id).toBeInstanceOf(FindOperator);
+      expect(boundValues(query._id)).toEqual([ownedDashboardId.toString()]);
+    });
+
+    test("an Owned-scoped Viewer who owns no dashboard sees none", async () => {
+      jest
+        .spyOn(OwnedScopePermission as any, "getAllowedResourceIds")
+        .mockResolvedValue([]);
+
+      const query: any = await OwnedScopePermission.addOwnedScopeToQuery(
+        Dashboard,
+        { projectId } as any,
+        makeProps([Permission.Viewer], PermissionScope.Owned),
+        DatabaseRequestType.Read,
+      );
+
+      /*
+       * Matches nothing rather than everything. A dashboard with an empty
+       * Owners list is owned by nobody, so it drops out of the result for
+       * every Owned-scoped reader - which is the behaviour the report asked
+       * for.
+       */
+      expect(query._id).toBeInstanceOf(FindOperator);
+      expect(boundValues(query._id)).toEqual([
+        ObjectID.getZeroObjectID().toString(),
+      ]);
+    });
+
+    /*
+     * The scope the reported team actually had. Documented here so the
+     * difference between the two configurations is not folklore.
+     */
+    test("an All-scoped Viewer is not narrowed to owned dashboards", async () => {
+      jest
+        .spyOn(OwnedScopePermission as any, "getAllowedResourceIds")
+        .mockResolvedValue([ownedDashboardId]);
+
+      const query: any = await OwnedScopePermission.addOwnedScopeToQuery(
+        Dashboard,
+        { projectId } as any,
+        makeProps([Permission.Viewer], PermissionScope.All),
+        DatabaseRequestType.Read,
+      );
+
+      expect(query._id).toBeUndefined();
+    });
+  });
+});

package/Tests/Server/Types/Database/QueryHelperOperators.test.ts

@@ -1,4 +1,5 @@
 import QueryHelper from "../../../../Server/Types/Database/QueryHelper";
+import ObjectID from "../../../../Types/ObjectID";
 import { FindOperator } from "typeorm";
 import { describe, expect, it } from "@jest/globals";
 
@@ -64,6 +65,22 @@ describe("QueryHelper comparison operators — exact rendered SQL", () => {
       expect(operator.objectLiteralParameters[param]).toBe(5);
     });
 
+    it("greaterThan stringifies and binds an ObjectID cursor", () => {
+      const cursor: ObjectID = new ObjectID(
+        "11111111-1111-4111-8111-111111111111",
+      );
+      const operator: RawOperator = asRaw(QueryHelper.greaterThan(cursor));
+      const param: string = soleParamName(operator);
+      const alias: string = '"NetworkSite"."_id"';
+      const sql: string = operator.getSql(alias);
+
+      expect(sql).toBe(`(${alias} > :${param})`);
+      expect(sql).not.toContain(cursor.toString());
+      expect(sql).not.toContain(">=");
+      expect(operator.objectLiteralParameters[param]).toBe(cursor.toString());
+      expect(operator.objectLiteralParameters[param]).not.toBe(cursor);
+    });
+
     it("greaterThanEqualTo emits an INCLUSIVE `>=`", () => {
       const operator: RawOperator = asRaw(QueryHelper.greaterThanEqualTo(5));
 

package/Tests/Server/Utils/AI/AlertMonitorFilters.test.ts

@@ -51,6 +51,7 @@ function buildAlert(data?: {
   number?: number;
   title?: string;
   state?: string;
+  monitorName?: string;
 }): Alert {
   const alert: Alert = new Alert();
   alert._id = ObjectID.generate().toString();
@@ -58,6 +59,15 @@ function buildAlert(data?: {
   alert.alertNumber = data?.number ?? 42;
   alert.createdAt = new Date("2026-08-01T00:00:00Z");
 
+  /*
+   * Left unset on purpose when no name is given: an alert can be raised by
+   * hand or by a workflow, with no monitor behind it at all, and that shape
+   * has to survive serialization too.
+   */
+  if (data?.monitorName) {
+    alert.monitor = buildMonitor({ name: data.monitorName });
+  }
+
   const state: AlertState = new AlertState();
   state.name = data?.state ?? "Created";
   alert.currentAlertState = state;
@@ -308,6 +318,120 @@ describe("query_alerts — detail mode owners", () => {
   });
 });
 
+/*
+ * The alerts page ships "Which monitor or source is generating the most alerts
+ * recently?" as a first-class suggested prompt, and query_alerts is the only
+ * tool that can answer it. Until an alert row carried the monitor it was
+ * raised for, the model had nothing to group by and could only guess a source
+ * out of alert titles. So the monitor is pinned in two places here: the select
+ * that reaches the database (a column that is never selected can never be
+ * returned, no matter what the row mapper does) and the serialized rows the
+ * model actually reads.
+ */
+describe("query_alerts — originating monitor", () => {
+  test("the list branch selects and returns the monitor each alert was raised for", async () => {
+    const findBySpy: jest.SpyInstance = jest
+      .spyOn(AlertService, "findBy")
+      .mockResolvedValue([
+        buildAlert({ title: "Latency spike", monitorName: "Payments API" }),
+        buildAlert({ title: "5xx rate high", monitorName: "Checkout Web" }),
+      ] as never);
+    jest
+      .spyOn(AlertService, "countBy")
+      .mockResolvedValue(new PositiveNumber(2) as never);
+
+    const result: ToolExecutionResult = await QueryAlertsTool.execute(
+      { state: "active" },
+      ctx,
+    );
+
+    const select: JSONObject = (findBySpy.mock.calls[0]?.[0] as JSONObject)[
+      "select"
+    ] as JSONObject;
+    expect(select["monitor"]).toEqual({ name: true });
+
+    // One monitor per row — grouping by source is only possible if each row names its own.
+    expect(result.dataForLlm).toContain("monitor=Payments API");
+    expect(result.dataForLlm).toContain("monitor=Checkout Web");
+
+    /*
+     * The widget is built from the same rows, so the field travels in its
+     * payload too. EntityListWidget does not render a monitor today — this
+     * pins the payload shape, not a user-visible outcome.
+     */
+    const items: Array<JSONObject> = result.widget?.data.items ?? [];
+    expect(items).toHaveLength(2);
+    expect(items[0]?.["monitor"]).toBe("Payments API");
+    expect(items[1]?.["monitor"]).toBe("Checkout Web");
+  });
+
+  test("the single-alert branch selects and returns the originating monitor too", async () => {
+    const alertId: ObjectID = ObjectID.generate();
+
+    const findOneByIdSpy: jest.SpyInstance = jest
+      .spyOn(AlertService, "findOneById")
+      .mockResolvedValue(
+        buildAlert({
+          title: "Latency spike",
+          monitorName: "Payments API",
+        }) as never,
+      );
+    jest.spyOn(AlertOwnerTeamService, "findBy").mockResolvedValue([] as never);
+    jest.spyOn(AlertOwnerUserService, "findBy").mockResolvedValue([] as never);
+
+    const result: ToolExecutionResult = await QueryAlertsTool.execute(
+      { alertId: alertId.toString() },
+      ctx,
+    );
+
+    const select: JSONObject = (
+      findOneByIdSpy.mock.calls[0]?.[0] as JSONObject
+    )["select"] as JSONObject;
+    expect(select["monitor"]).toEqual({ name: true });
+
+    /*
+     * "What is this alert even watching?" is the first question asked of a
+     * single alert, and the detail row is the only place it can be answered.
+     */
+    expect(result.dataForLlm).toContain("monitor=Payments API");
+  });
+
+  test("an alert with no monitor serializes cleanly and emits no monitor field", async () => {
+    jest
+      .spyOn(AlertService, "findBy")
+      .mockResolvedValue([buildAlert({ title: "Raised by hand" })] as never);
+    jest
+      .spyOn(AlertService, "countBy")
+      .mockResolvedValue(new PositiveNumber(1) as never);
+
+    const result: ToolExecutionResult = await QueryAlertsTool.execute(
+      { state: "active" },
+      ctx,
+    );
+
+    expect(result.rowCount).toBe(1);
+    expect(result.dataForLlm).toContain("Raised by hand");
+
+    /*
+     * Nothing is better than something wrong here: the field is dropped
+     * outright rather than emitted as an empty or "undefined" source that the
+     * model would then count as a monitor of its own.
+     */
+    expect(result.dataForLlm).not.toContain("monitor=");
+    const items: Array<JSONObject> = result.widget?.data.items ?? [];
+    expect(items[0]?.["monitor"]).toBeUndefined();
+  });
+
+  test("the tool description advertises the monitor so the model plans around it", () => {
+    /*
+     * The model chooses tools from their descriptions, not from the shape of
+     * results it has not fetched yet. A field nothing advertises is a field it
+     * will not go looking for.
+     */
+    expect(QueryAlertsTool.description.toLowerCase()).toContain("monitor");
+  });
+});
+
 describe("query_monitors — problemsOnly filter", () => {
   test("problemsOnly=true filters on isOperationalState=false at the DB level", async () => {
     const downStatus: MonitorStatus = buildMonitorStatus({