@oneuptime/common 12.0.17 → 12.0.19

package/Tests/Models/DatabaseModels/MonitorSecretKeyColumnAccessControl.test.ts

@@ -0,0 +1,214 @@
+import Monitor from "../../../Models/DatabaseModels/Monitor";
+import { ColumnAccessControl } from "../../../Types/BaseDatabase/AccessControl";
+import Dictionary from "../../../Types/Dictionary";
+import Permission, { PermissionHelper } from "../../../Types/Permission";
+import { describe, expect, it } from "@jest/globals";
+
+/*
+ * https://github.com/OneUptime/oneuptime/issues/3360
+ *
+ * Monitor carries three bearer credentials as ordinary columns:
+ *
+ *   serverMonitorSecretKey    - authenticates every host agent reporting in
+ *   incomingRequestSecretKey  - IS the heartbeat URL
+ *   incomingEmailSecretKey    - IS the monitor's inbound address
+ *
+ * All three used to list Permission.Viewer in their read ACL. Viewer is the
+ * least privilege OneUptime offers and is precisely what gets handed to a
+ * dashboard, an auditor, a contractor or an automation -- so "read-only" also
+ * meant "can read a live credential and then forge or suppress this monitor's
+ * heartbeats". Redacting the secret out of MonitorLog.logBody (the other half
+ * of the fix) does nothing about this path: it is a plain column select.
+ *
+ * The rule these tests encode is a single sentence: reading a monitor secret
+ * requires the ability to ROTATE it. Anything weaker is a credential handed to
+ * someone who cannot revoke it.
+ */
+
+const SECRET_KEY_COLUMNS: Array<string> = [
+  "serverMonitorSecretKey",
+  "incomingRequestSecretKey",
+  "incomingEmailSecretKey",
+];
+
+/*
+ * The read-only roles. Every one of these was on the read list before the fix,
+ * and none of them can rotate a key.
+ */
+const READ_ONLY_PERMISSIONS: Array<Permission> = [
+  Permission.Viewer,
+  Permission.MonitorViewer,
+  Permission.ReadProjectMonitor,
+];
+
+// The roles that can reset a monitor secret, and so may also see it.
+const ROTATION_PERMISSIONS: Array<Permission> = [
+  Permission.ProjectOwner,
+  Permission.ProjectAdmin,
+  Permission.ProjectMember,
+  Permission.MonitorAdmin,
+  Permission.MonitorMember,
+  Permission.EditProjectMonitor,
+];
+
+const accessControl: Dictionary<ColumnAccessControl> =
+  new Monitor().getColumnAccessControlForAllColumns();
+
+type CanReadFunction = (
+  columnName: string,
+  userPermissions: Array<Permission>,
+) => boolean;
+
+/*
+ * ColumnPermission.checkDataColumnPermissions, reduced to the question that
+ * matters. Note what the server does when this is false: it THROWS
+ * `User is not allowed to read on <column> column of Monitor` and the whole
+ * request fails. There is no partial response -- which is why the dashboard
+ * has to gate the select rather than the render.
+ */
+const canRead: CanReadFunction = (
+  columnName: string,
+  userPermissions: Array<Permission>,
+): boolean => {
+  const columnPermissions: Array<Permission> =
+    accessControl[columnName]?.read || [];
+
+  return PermissionHelper.doesPermissionsIntersect(
+    userPermissions,
+    columnPermissions,
+  );
+};
+
+describe("Monitor secret key columns are not readable by read-only roles", () => {
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s is unreadable by a Viewer-only principal",
+    (columnName: string) => {
+      /*
+       * This is step 2 of the reproduction in the issue: an API key whose only
+       * permission is Viewer.
+       */
+      expect(canRead(columnName, [Permission.Viewer])).toBe(false);
+    },
+  );
+
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s is unreadable by every read-only role, individually",
+    (columnName: string) => {
+      for (const permission of READ_ONLY_PERMISSIONS) {
+        expect(canRead(columnName, [permission])).toBe(false);
+      }
+    },
+  );
+
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s is unreadable even when all the read-only roles are held at once",
+    (columnName: string) => {
+      /*
+       * Intersection semantics mean any single surviving read-only permission
+       * re-opens the hole, so hold them all and assert the union is still
+       * refused.
+       */
+      expect(canRead(columnName, READ_ONLY_PERMISSIONS)).toBe(false);
+    },
+  );
+
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s names none of the read-only roles in its read ACL",
+    (columnName: string) => {
+      const readPermissions: Array<Permission> =
+        accessControl[columnName]?.read || [];
+
+      for (const permission of READ_ONLY_PERMISSIONS) {
+        expect(readPermissions).not.toContain(permission);
+      }
+    },
+  );
+});
+
+describe("Monitor secret key columns stay readable by the roles that can rotate them", () => {
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s is readable by each rotation-capable role",
+    (columnName: string) => {
+      /*
+       * The other failure mode. Locking these down too far breaks Monitor >
+       * Settings for a project member, who legitimately needs the key to set
+       * an agent up.
+       */
+      for (const permission of ROTATION_PERMISSIONS) {
+        expect(canRead(columnName, [permission])).toBe(true);
+      }
+    },
+  );
+
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s gates read on exactly the same roles as update",
+    (columnName: string) => {
+      /*
+       * The invariant, stated directly: you may see a monitor secret if and
+       * only if you may replace it. If someone later widens read without
+       * widening update, this is the test that should stop them and make them
+       * say why.
+       */
+      const column: ColumnAccessControl | undefined = accessControl[columnName];
+
+      expect(column).toBeDefined();
+      expect([...(column?.read || [])].sort()).toEqual(
+        [...(column?.update || [])].sort(),
+      );
+    },
+  );
+
+  it.each(SECRET_KEY_COLUMNS)(
+    "%s is never writable on create",
+    (columnName: string) => {
+      // The keys are computed server-side by MonitorService, never supplied.
+      expect(accessControl[columnName]?.create || []).toEqual([]);
+    },
+  );
+});
+
+describe("the rest of the monitor page still loads for a Viewer", () => {
+  /*
+   * Tightening the secret columns must not collaterally break the monitor view
+   * for read-only users: an unreadable column in a select fails the WHOLE
+   * request, so if any of these regressed, a Viewer would get an error screen
+   * instead of a monitor. These are the other columns
+   * Pages/Monitor/View/Index.tsx asks for.
+   */
+  const VIEWER_READABLE_COLUMNS: Array<string> = [
+    "monitorType",
+    "serverMonitorRequestReceivedAt",
+    "incomingRequestMonitorHeartbeatCheckedAt",
+    "incomingEmailMonitorHeartbeatCheckedAt",
+    "incomingEmailMonitorLastEmailReceivedAt",
+    "monitorSteps",
+  ];
+
+  it.each(VIEWER_READABLE_COLUMNS)(
+    "%s is still readable by a Viewer",
+    (columnName: string) => {
+      expect(canRead(columnName, [Permission.Viewer])).toBe(true);
+    },
+  );
+});
+
+describe("the payload columns rely on redaction, not on access control", () => {
+  /*
+   * serverMonitorResponse and incomingMonitorRequest are the OTHER two places
+   * the agent payload lands, and both remain Viewer-readable -- deliberately:
+   * they are what the monitor page renders. That is exactly why the secret has
+   * to be stripped at the ingest boundary (see MonitorPayloadRedaction) rather
+   * than merely hidden behind a permission. If someone ever removes that
+   * strip, no ACL here will catch it.
+   *
+   * This test is a signpost, not a guard. If these columns are deliberately
+   * locked down later, delete it -- but do not delete the redaction.
+   */
+  it("serverMonitorResponse is readable by a Viewer", () => {
+    expect(canRead("serverMonitorResponse", [Permission.Viewer])).toBe(true);
+  });
+
+  it("incomingMonitorRequest is readable by a Viewer", () => {
+    expect(canRead("incomingMonitorRequest", [Permission.Viewer])).toBe(true);
+  });
+});

package/Tests/Server/API/OnCallReadinessAPI.test.ts

@@ -26,9 +26,11 @@ import TeamMemberService from "../../../Server/Services/TeamMemberService";
 import TeamService from "../../../Server/Services/TeamService";
 import UserCallService from "../../../Server/Services/UserCallService";
 import UserEmailService from "../../../Server/Services/UserEmailService";
+import UserMicrosoftTeamsService from "../../../Server/Services/UserMicrosoftTeamsService";
 import UserNotificationRuleService from "../../../Server/Services/UserNotificationRuleService";
 import UserPushService from "../../../Server/Services/UserPushService";
 import UserService from "../../../Server/Services/UserService";
+import UserSlackService from "../../../Server/Services/UserSlackService";
 import UserSmsService from "../../../Server/Services/UserSmsService";
 import UserTelegramService from "../../../Server/Services/UserTelegramService";
 import UserWebhookService from "../../../Server/Services/UserWebhookService";
@@ -41,7 +43,9 @@ import {
 import Response from "../../../Server/Utils/Response";
 import UserCall from "../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserPush from "../../../Models/DatabaseModels/UserPush";
+import UserSlack from "../../../Models/DatabaseModels/UserSlack";
 import UserSMS from "../../../Models/DatabaseModels/UserSMS";
 import UserTelegram from "../../../Models/DatabaseModels/UserTelegram";
 import UserWebhook from "../../../Models/DatabaseModels/UserWebhook";
@@ -316,6 +320,8 @@ let userSmsFindBy: jest.SpyInstance;
 let userCallFindBy: jest.SpyInstance;
 let userWhatsAppFindBy: jest.SpyInstance;
 let userTelegramFindBy: jest.SpyInstance;
+let userSlackFindBy: jest.SpyInstance;
+let userMicrosoftTeamsFindBy: jest.SpyInstance;
 let userWebhookFindBy: jest.SpyInstance;
 let notificationRuleFindBy: jest.SpyInstance;
 let incidentSeverityFindBy: jest.SpyInstance;
@@ -340,6 +346,8 @@ function everyFindBySpy(): Array<jest.SpyInstance> {
     userCallFindBy,
     userWhatsAppFindBy,
     userTelegramFindBy,
+    userSlackFindBy,
+    userMicrosoftTeamsFindBy,
     userWebhookFindBy,
     notificationRuleFindBy,
     incidentSeverityFindBy,
@@ -445,6 +453,12 @@ beforeEach(() => {
   userTelegramFindBy = jest
     .spyOn(UserTelegramService, "findBy")
     .mockResolvedValue([] as never);
+  userSlackFindBy = jest
+    .spyOn(UserSlackService, "findBy")
+    .mockResolvedValue([] as never);
+  userMicrosoftTeamsFindBy = jest
+    .spyOn(UserMicrosoftTeamsService, "findBy")
+    .mockResolvedValue([] as never);
   userWebhookFindBy = jest
     .spyOn(UserWebhookService, "findBy")
     .mockResolvedValue([] as never);
@@ -759,13 +773,14 @@ describe("GET /on-call-readiness/policy/:policyId", () => {
 
     /*
      * Four fields and no fifth. `methods` is the part of this payload that
-     * describes rows an administrator is NOT permitted to read - the seven
+     * describes rows an administrator is NOT permitted to read - the nine
      * method models are owner-scoped precisely because their columns are the raw
-     * phone number, the webhook bearer url, the push token, the telegram chat id
-     * and the verification code - so the wire shape is asserted exhaustively
-     * rather than field by field. A field added to ReadinessMethod is a field
-     * that ships to every administrator of the project, and it should have to
-     * pass through here on the way.
+     * phone number, the webhook bearer url, the push token, the telegram chat
+     * id, the slack member id, the teams object id and the verification code -
+     * so the wire shape is asserted exhaustively rather than field by field. A
+     * field added to ReadinessMethod is a field that ships to every
+     * administrator of the project, and it should have to pass through here on
+     * the way.
      */
     expect(user["methods"]).toEqual([
       {
@@ -1437,6 +1452,15 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
   const RAW_WHATSAPP: string = "+14155559999";
   const RAW_HANDLE: string = "@jamesbond";
   const RAW_DEVICE: string = "Jane's iPhone 15 Pro";
+  const RAW_SLACK_USERNAME: string = "jane.oncall.slack";
+  const RAW_TEAMS_USERNAME: string = "Jane Doe [Overnight]";
+  /*
+   * The addressable targets behind the two workspace channels - the Slack
+   * member id the bot DMs and the Entra object id the Teams bot resolves. On
+   * the rows, like the webhook's bearer url, and never selected.
+   */
+  const RAW_SLACK_USER_ID: string = "U0MEMBERIDLEAK";
+  const RAW_TEAMS_USER_ID: string = "aad-ENTRALEAK-7788";
   const RAW_WEBHOOK_NAME: string = "Payments Slack Hook";
   const RAW_WEBHOOK_URL: string =
     "https://hooks.slack.com/services/T000/B000/XXXXsecretXXXX";
@@ -1445,7 +1469,7 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
    * One fixed id per channel, and fixed rather than generated so that a failure
    * prints a value a reader can match against the fixture that produced it.
    *
-   * These are the ids UserNotificationRule's seven foreign keys reference -
+   * These are the ids UserNotificationRule's nine foreign keys reference -
    * userEmailId points at a UserEmail row, userSmsId at a UserSMS row - and they
    * are the reason `methodId` exists at all. An administrator building a rule
    * for somebody else may not READ any of these rows; what they get instead is
@@ -1475,10 +1499,16 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
   const WEBHOOK_METHOD_ID: ObjectID = new ObjectID(
     "1a000000-0000-4000-8000-000000000007",
   );
+  const SLACK_METHOD_ID: ObjectID = new ObjectID(
+    "1a000000-0000-4000-8000-000000000008",
+  );
+  const MICROSOFT_TEAMS_METHOD_ID: ObjectID = new ObjectID(
+    "1a000000-0000-4000-8000-000000000009",
+  );
 
   /*
    * The expected id per channel, in one place, so the sweep below is a sweep
-   * over all seven rather than seven assertions that can each be forgotten
+   * over all nine rather than nine assertions that can each be forgotten
    * individually. Keyed by the wire's `methodType` string.
    */
   const METHOD_ID_BY_TYPE: Dictionary<string> = {
@@ -1488,6 +1518,8 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     [ReadinessMethodType.Call]: CALL_METHOD_ID.toString(),
     [ReadinessMethodType.WhatsApp]: WHATSAPP_METHOD_ID.toString(),
     [ReadinessMethodType.Telegram]: TELEGRAM_METHOD_ID.toString(),
+    [ReadinessMethodType.Slack]: SLACK_METHOD_ID.toString(),
+    [ReadinessMethodType.MicrosoftTeams]: MICROSOFT_TEAMS_METHOD_ID.toString(),
     [ReadinessMethodType.Webhook]: WEBHOOK_METHOD_ID.toString(),
   };
 
@@ -1548,6 +1580,24 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     telegram.isVerified = true;
     userTelegramFindBy.mockResolvedValue([telegram] as never);
 
+    const slack: UserSlack = new UserSlack();
+    slack.id = SLACK_METHOD_ID;
+    slack.userId = subjectUserId;
+    slack.slackUserName = RAW_SLACK_USERNAME;
+    // On the row, and never selected: the member id is the addressable target.
+    slack.slackUserId = RAW_SLACK_USER_ID;
+    slack.isVerified = true;
+    userSlackFindBy.mockResolvedValue([slack] as never);
+
+    const microsoftTeams: UserMicrosoftTeams = new UserMicrosoftTeams();
+    microsoftTeams.id = MICROSOFT_TEAMS_METHOD_ID;
+    microsoftTeams.userId = subjectUserId;
+    microsoftTeams.microsoftTeamsUserName = RAW_TEAMS_USERNAME;
+    // On the row, and never selected: the Entra id is the addressable target.
+    microsoftTeams.microsoftTeamsUserId = RAW_TEAMS_USER_ID;
+    microsoftTeams.isVerified = true;
+    userMicrosoftTeamsFindBy.mockResolvedValue([microsoftTeams] as never);
+
     const push: UserPush = new UserPush();
     push.id = PUSH_METHOD_ID;
     push.userId = subjectUserId;
@@ -1597,6 +1647,24 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
         maskedIdentifier: `j${IDENTIFIER_MASK}@personal.example.com`,
         isVerified: true,
       },
+      /*
+       * The two workspace channels sit in the zero-cost tier beside Push and
+       * Email, ahead of every paid channel. Their masked identifier is the
+       * human-facing NAME column under the handle rule; the addressable ids
+       * are never selected at all - see the select tests below.
+       */
+      {
+        methodId: SLACK_METHOD_ID.toString(),
+        methodType: ReadinessMethodType.Slack,
+        maskedIdentifier: `ja${IDENTIFIER_MASK}`,
+        isVerified: true,
+      },
+      {
+        methodId: MICROSOFT_TEAMS_METHOD_ID.toString(),
+        methodType: ReadinessMethodType.MicrosoftTeams,
+        maskedIdentifier: `Ja${IDENTIFIER_MASK}`,
+        isVerified: true,
+      },
       {
         methodId: SMS_METHOD_ID.toString(),
         methodType: ReadinessMethodType.SMS,
@@ -1634,10 +1702,10 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     ]);
   });
 
-  test("all seven channels reach the wire carrying the id of their OWN row", async () => {
+  test("all nine channels reach the wire carrying the id of their OWN row", async () => {
     /*
      * The dropdown's entire premise, swept across every channel rather than
-     * spot-checked on one, because the seven are seven separate code paths that
+     * spot-checked on one, because the nine are nine separate code paths that
      * each build their own row and each have their own opportunity to hand over
      * somebody else's id - or none at all.
      *
@@ -1650,7 +1718,7 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     const payload: Record<string, unknown> = await readUser();
     const methods: Array<Record<string, unknown>> = methodsOf(payload);
 
-    expect(methods).toHaveLength(7);
+    expect(methods).toHaveLength(9);
 
     for (const method of methods) {
       const methodType: string = method["methodType"] as string;
@@ -1682,7 +1750,7 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     const payload: Record<string, unknown> = await readUser();
     const methods: Array<Record<string, unknown>> = methodsOf(payload);
 
-    expect(methods).toHaveLength(7);
+    expect(methods).toHaveLength(9);
 
     for (const method of methods) {
       expect(method["methodId"]).not.toBe(subjectUserId.toString());
@@ -1691,23 +1759,23 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
       expect(method["methodId"]).not.toBe(projectId.toString());
     }
 
-    // And all seven are distinct - one id copied across channels is the same bug.
+    // And all nine are distinct - one id copied across channels is the same bug.
     const ids: Array<unknown> = methods.map(
       (method: Record<string, unknown>): unknown => {
         return method["methodId"];
       },
     );
-    expect(new Set(ids).size).toBe(7);
+    expect(new Set(ids).size).toBe(9);
   });
 
   test("a method carries its id, its type, its mask and its verification - and nothing else", async () => {
     /*
      * The containment assertion. Every field on this object ships to every
      * administrator of the project, about a row that administrator is not
-     * allowed to read, so the key set is pinned exhaustively on all seven rather
+     * allowed to read, so the key set is pinned exhaustively on all nine rather
      * than left to whatever the serialiser happens to copy. A `phone`, a
-     * `webhookUrl` or a `telegramChatId` appearing here is not a formatting
-     * change; it is the exposure this design was built to avoid.
+     * `webhookUrl`, a `telegramChatId` or a `slackUserId` appearing here is not
+     * a formatting change; it is the exposure this design was built to avoid.
      */
     const payload: Record<string, unknown> = await readUser();
 
@@ -1729,10 +1797,10 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
      * Guards the guard, and it is not a formality here: the service drops any
      * method row it cannot find an id on, so a fixture regression that emptied
      * `methods` would satisfy every "not present" assertion below for the one
-     * reason that proves nothing at all. The seven masks have to be in the body
+     * reason that proves nothing at all. The nine masks have to be in the body
      * before their absence of raw values means anything.
      */
-    expect(methodsOf(payload)).toHaveLength(7);
+    expect(methodsOf(payload)).toHaveLength(9);
     expect(body).toContain(IDENTIFIER_MASK);
 
     /*
@@ -1747,6 +1815,8 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
       RAW_WHATSAPP,
       RAW_HANDLE,
       RAW_DEVICE,
+      RAW_SLACK_USERNAME,
+      RAW_TEAMS_USERNAME,
       RAW_WEBHOOK_NAME,
       RAW_WEBHOOK_URL,
       // The notification address's local part on its own, and the hook's host.
@@ -1754,6 +1824,14 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
       "hooks.slack.com",
       // The telegram chat id - the addressable target, never the label.
       "998877",
+      // The workspace targets - the Slack member id and the Entra object id.
+      RAW_SLACK_USER_ID,
+      RAW_TEAMS_USER_ID,
+      "MEMBERIDLEAK",
+      "ENTRALEAK",
+      // The workspace names' revealing middles, past what a handle mask keeps.
+      "oncall.slack",
+      "[Overnight]",
       /*
        * The unmasked tails of the four phone-shaped identifiers. maskIdentifier
        * keeps the last four digits on purpose, so the numbers themselves are
@@ -1795,7 +1873,7 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     const payload: Record<string, unknown> = await readUser();
     const methods: Array<Record<string, unknown>> = methodsOf(payload);
 
-    expect(methods).toHaveLength(7);
+    expect(methods).toHaveLength(9);
 
     for (const method of methods) {
       expect(method["methodId"]).not.toBe(ruleId.toString());
@@ -1870,6 +1948,24 @@ describe("GET /on-call-readiness/user/:userId - identifier masking", () => {
     expect(call.select?.["telegramUserHandle"]).toBe(true);
     expect(call.select?.["telegramChatId"]).toBeUndefined();
   });
+
+  test("the slack read takes the username, never the addressable member id", async () => {
+    await readUser();
+
+    const call: CapturedFindBy = firstCall(userSlackFindBy);
+
+    expect(call.select?.["slackUserName"]).toBe(true);
+    expect(call.select?.["slackUserId"]).toBeUndefined();
+  });
+
+  test("the microsoft teams read takes the display name, never the addressable entra id", async () => {
+    await readUser();
+
+    const call: CapturedFindBy = firstCall(userMicrosoftTeamsFindBy);
+
+    expect(call.select?.["microsoftTeamsUserName"]).toBe(true);
+    expect(call.select?.["microsoftTeamsUserId"]).toBeUndefined();
+  });
 });
 
 /*
@@ -1898,6 +1994,8 @@ interface StubRule {
   userEmailId?: ObjectID | undefined;
   userPushId?: ObjectID | undefined;
   userTelegramId?: ObjectID | undefined;
+  userSlackId?: ObjectID | undefined;
+  userMicrosoftTeamsId?: ObjectID | undefined;
   userWhatsAppId?: ObjectID | undefined;
   userWebhookId?: ObjectID | undefined;
 }
@@ -2037,17 +2135,22 @@ describe("GET /team/compliance-status/:teamId - the rebuilt service", () => {
     ]);
   });
 
-  test("DEFECT closed: a rule on Telegram, WhatsApp or a webhook now counts", async () => {
+  test("DEFECT closed: a rule on Telegram, WhatsApp, Slack, Teams or a webhook now counts", async () => {
     /*
      * The old check read userCallId/userSmsId/userEmailId/userPushId off the
      * rule row and treated a row carrying none of them as no rule at all, so a
      * responder reachable only on Telegram, WhatsApp or a webhook was reported
      * non-compliant while the runtime was quite happily paging them. A false RED
-     * teaches admins to ignore the table, which is worse than no table.
+     * teaches admins to ignore the table, which is worse than no table. Slack
+     * and Microsoft Teams arrived after the fix and are staged alongside so the
+     * defect cannot return for the channels that never lived through it.
      *
-     * All three channels are staged onto one user at once: whichever column the
+     * All five channels are staged onto one user at once: whichever column the
      * rule carries, the row is a rule.
      */
+    const minor: StubSeverity = { id: ObjectID.generate(), name: "Minor" };
+    const warn: StubSeverity = { id: ObjectID.generate(), name: "Warn" };
+
     stage({
       settings: [
         { ruleType: ComplianceRuleType.HasIncidentOnCallRules, enabled: true },
@@ -2069,6 +2172,13 @@ describe("GET /team/compliance-status/:teamId - the rebuilt service", () => {
           incidentSeverityId: major.id,
           userWhatsAppId: ObjectID.generate(),
         },
+        {
+          _id: "rule-slack",
+          userId: ada.id,
+          ruleType: NotificationRuleType.ON_CALL_EXECUTED_INCIDENT,
+          incidentSeverityId: minor.id,
+          userSlackId: ObjectID.generate(),
+        },
         {
           _id: "rule-webhook",
           userId: ada.id,
@@ -2076,9 +2186,16 @@ describe("GET /team/compliance-status/:teamId - the rebuilt service", () => {
           alertSeverityId: page.id,
           userWebhookId: ObjectID.generate(),
         },
+        {
+          _id: "rule-microsoft-teams",
+          userId: ada.id,
+          ruleType: NotificationRuleType.ON_CALL_EXECUTED_ALERT,
+          alertSeverityId: warn.id,
+          userMicrosoftTeamsId: ObjectID.generate(),
+        },
       ],
-      incidentSeverities: [critical, major],
-      alertSeverities: [page],
+      incidentSeverities: [critical, major, minor],
+      alertSeverities: [page, warn],
     });
 
     const statuses: Array<Record<string, unknown>> = statusesOf(
@@ -2093,7 +2210,7 @@ describe("GET /team/compliance-status/:teamId - the rebuilt service", () => {
     /*
      * The structural half of the fix. The three formerly-invisible channels were
      * invisible because they were never SELECTed; asserting that NONE of the
-     * seven is selected means no future edit can reintroduce a partial column
+     * nine is selected means no future edit can reintroduce a partial column
      * list and quietly start under-counting again.
      */
     stage({
@@ -2116,6 +2233,8 @@ describe("GET /team/compliance-status/:teamId - the rebuilt service", () => {
       "userEmailId",
       "userPushId",
       "userTelegramId",
+      "userSlackId",
+      "userMicrosoftTeamsId",
       "userWhatsAppId",
       "userWebhookId",
     ]) {

package/Tests/Server/API/UserNotificationMethodAdminAPI.test.ts

@@ -30,7 +30,7 @@ import { beforeEach, describe, expect, test } from "@jest/globals";
  * methods".
  *
  * This router is the ONLY gate under these routes, and that is not a stylistic
- * observation. The seven notification method models are scoped to the person
+ * observation. The nine notification method models are scoped to the person
  * who owns the device — the essay at the top of UserEmail.ts is the record of
  * what happened the one time that scope was widened — so the service behind
  * these handlers does every read and write with `isRoot: true`, which means the
@@ -362,7 +362,7 @@ describe("the routes it registers", () => {
      * Extending BaseAPI to inherit `this.router` would register a whole model's
      * CRUD routes as a side effect — dead code that is shadowed by the real
      * registration until the day the mount order changes. There is no model to
-     * inherit here in any case: the seven method models stay owner-scoped and
+     * inherit here in any case: the nine method models stay owner-scoped and
      * this router deliberately never exposes them.
      */
     expect(UserNotificationMethodAdminAPI).toBe(mockRouter);

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

@@ -459,7 +459,17 @@ describe("LlmLogService autonomous-token lane isolation", () => {
     expect(sql).toContain('FROM "AIRun" AS "run"');
     expect(sql).toContain('"run"."triggeredByIncidentId" IS NOT NULL');
     expect(params[3]).toEqual(legacyIncidentFeatures);
-    expect(params[4]).toEqual(legacyAlertFeatures);
+
+    /*
+     * The incident lane reads only its own legacy list, so it must bind
+     * exactly four parameters. Binding the unread alert list as $5 is what
+     * PostgreSQL rejected with "bind message supplies 5 parameters, but
+     * prepared statement "" requires 4", which silently disabled every capped
+     * incident investigation. LlmLogServiceTokenAggregateParams.test.ts holds
+     * the exhaustive placeholder/binding contract.
+     */
+    expect(params).toHaveLength(4);
+    expect(sql).not.toContain("$5");
   });
 
   test("subjectless totals exclude identifiable legacy incident and alert rows", async () => {