@oneuptime/common 12.0.17 → 12.0.19

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

@@ -59,7 +59,7 @@ import getJestMockFunction, { MockFunction } from "../../MockType";
  *     to be tempted will add a button, not a sentence.
  *
  *   - AN ADMIN READING SOMEBODY ELSE'S PHONE NUMBER, which is the same defect
- *     one step earlier and is what this page originally did. The seven method
+ *     one step earlier and is what this page originally did. The nine method
  *     models are scoped to the person who owns the device - the columns behind
  *     them are the raw number, the webhook bearer url, the push device token,
  *     the telegram chat id and the verification code - and that scope was
@@ -389,8 +389,10 @@ import TeamMember from "../../../Models/DatabaseModels/TeamMember";
 import User from "../../../Models/DatabaseModels/User";
 import UserCall from "../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../Models/DatabaseModels/UserNotificationRule";
 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";
@@ -413,7 +415,7 @@ const PROJECT_ID: ObjectID = new ObjectID(PROJECT_ID_STRING);
 const SIGNED_IN_USER_ID: ObjectID = new ObjectID(SIGNED_IN_USER_ID_STRING);
 
 /*
- * The seven models only their owner may read. They are asserted as a SET because
+ * The nine models only their owner may read. They are asserted as a SET because
  * which one an admin surface reaches for hardly matters - every one of them
  * carries a raw identifier and most carry a credential.
  */
@@ -424,11 +426,13 @@ const NOTIFICATION_METHOD_MODELS: Array<unknown> = [
   UserPush,
   UserWhatsApp,
   UserTelegram,
+  UserSlack,
+  UserMicrosoftTeams,
   UserWebhook,
 ];
 
 /*
- * The RELATION spelling of those same seven, as they appear in a nested select
+ * The RELATION spelling of those same nine, as they appear in a nested select
  * on UserNotificationRule. Selecting any of them pulls a column out of the
  * method model itself - the address, the number, the handle - through a table
  * an administrator may read and which is not row-scoped for them. It is the
@@ -442,6 +446,8 @@ const METHOD_RELATION_KEYS: Array<string> = [
   "userPush",
   "userWhatsApp",
   "userTelegram",
+  "userSlack",
+  "userMicrosoftTeams",
   "userWebhook",
 ];
 
@@ -453,6 +459,8 @@ const METHOD_FOREIGN_KEYS: Array<keyof UserNotificationRule> = [
   "userPushId",
   "userWhatsAppId",
   "userTelegramId",
+  "userSlackId",
+  "userMicrosoftTeamsId",
   "userWebhookId",
 ];
 
@@ -673,7 +681,7 @@ const setUpLists: SetUpListsFunction = (
     }
 
     /*
-     * Anything else, INCLUDING the seven notification-method models - which this
+     * Anything else, INCLUDING the nine notification-method models - which this
      * page must never ask for. A non-empty answer here would make a leak look
      * like a feature working, so the fallback stays empty and the assertion that
      * matters is about the request rather than the response: see "never reads a
@@ -1172,7 +1180,7 @@ afterEach(async (): Promise<void> => {
 
   /*
    * Unmounting stops the RENDERING, not the fetching. A rule table that belongs
-   * to the viewer loads the seven notification-method models one after another,
+   * to the viewer loads the nine notification-method models one after another,
    * so a test that reads its own page leaves a chain of awaits running after its
    * last assertion - and every one of those calls is recorded on the same
    * `getListMock` the next test resets and then asserts against.
@@ -1365,14 +1373,14 @@ describe("the page is read at rest, whichever order its fetches land in", () =>
     assertEveryTableIsSettled();
   });
 
-  test("waits out the seven method reads a self-serve page makes for its owner", async () => {
+  test("waits out the nine method reads a self-serve page makes for its owner", async () => {
     // A self-serve page is always the viewer's own, so this is the owner path.
     await renderSelfServePage(IncidentOnCallRules);
 
     /*
-     * A rule table belonging to the viewer loads the seven notification-method
+     * A rule table belonging to the viewer loads the nine notification-method
      * models one after another, and unmounting the page does not stop that
-     * chain - it stops the rendering. Any of those seven still running when the
+     * chain - it stops the rendering. Any of those nine still running when the
      * next test resets `getListMock` is recorded as that test's request, which
      * is how "never reads a notification method model" comes to fail on a page
      * that never asked for one.
@@ -1484,7 +1492,7 @@ describe("the shared rules table, as the admin page wires it", () => {
     /*
      * The redesign, in one assertion.
      *
-     * These seven models are readable only by the person who owns the row, and
+     * These nine models are readable only by the person who owns the row, and
      * that is the whole protection: the table scope pins every read to the
      * caller. Widening it so this page could fill a dropdown exposed the raw
      * email and phone, the webhook url, the push device token, the telegram chat
@@ -1619,7 +1627,7 @@ describe("the shared rules table, as the admin page wires it", () => {
       });
 
     /*
-     * The seven foreign keys are mutually exclusive, and writing an SMS id into
+     * The nine foreign keys are mutually exclusive, and writing an SMS id into
      * `userEmailId` would page an address instead of a phone without erroring
      * anywhere, so the whole set is asserted rather than the one column.
      */
@@ -1639,7 +1647,7 @@ describe("the shared rules table, as the admin page wires it", () => {
     /*
      * The failure mode this seam had to be designed around. Readiness is the
      * only source of methods here, so when it is down there are none to offer -
-     * and "then read the models directly" is not a fallback, it is seven refused
+     * and "then read the models directly" is not a fallback, it is nine refused
      * requests that would replace the rule tables with an error page. The rules
      * stay editable; only the method choice is missing.
      */
@@ -2002,7 +2010,7 @@ describe("methods are a page of their own now, not a card on this one", () => {
    * It asserted that an administrator was offered NO control for adding a
    * notification method to somebody else's account: a masked, read-only list
    * and a prefilled "please add one yourself" email. That was correct for what
-   * the server could do at the time - the seven method models are scoped to
+   * the server could do at the time - the nine method models are scoped to
    * their owner and the attempt to widen them leaked every raw column behind
    * them - but it left the commonest broken responder, a new joiner with no
    * method at all, fixable by nobody but themselves.
@@ -2167,7 +2175,7 @@ describe("the coverage grid, now shared with the readiness page", () => {
  * The edit path.
  *
  * `isEditable` was hardcoded false on the ModelTable, so this page issued no
- * PATCH at all: the phase opened `notifyAfterMinutes` (and the seven method
+ * PATCH at all: the phase opened `notifyAfterMinutes` (and the nine method
  * foreign keys) to update behind the largest guard in the codebase, and bought
  * zero capability anybody could reach. These assertions are about the two halves
  * of making that real - the editor being on for exactly the viewers allowed to
@@ -2225,7 +2233,7 @@ describe("the rules are editable, not merely addable and removable", () => {
 
     /*
      * The dropdown is an override field: its value travels in `miscDataProps`
-     * and is mapped onto one of the seven foreign keys by `onBeforeCreate`.
+     * and is mapped onto one of the nine foreign keys by `onBeforeCreate`.
      * ModelForm calls that hook only for FormType.Create and BaseAPI.updateItem
      * never reads `miscDataProps`, so on the edit path the choice is discarded
      * in transit. Rendering it anyway would give an administrator a control

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

@@ -33,7 +33,7 @@ import getJestMockFunction, { MockFunction } from "../../MockType";
  * decision satisfied by the new answer.
  *
  * The old surface showed a masked, read-only list and a prefilled "please add
- * one yourself" email, because the seven notification method models are scoped
+ * one yourself" email, because the nine notification method models are scoped
  * to the person who owns the device: the columns behind them are the raw
  * address, the phone number, the webhook bearer url, the push device token and
  * the verification code, and an attempt to widen that scope so an admin could
@@ -44,7 +44,7 @@ import getJestMockFunction, { MockFunction } from "../../MockType";
  * So the models are STILL owner-scoped, and this page talks to a narrow
  * server-side capability instead. What that buys, and what it must not:
  *
- *   - NO METHOD MODEL IS READ. Not by ModelAPI over UserEmail and its six
+ *   - NO METHOD MODEL IS READ. Not by ModelAPI over UserEmail and its eight
  *     siblings, and not through a nested relation select on a rule, which
  *     reaches the same columns through a table an administrator IS allowed to
  *     read. The assertion is about the REQUEST, because a component that asks
@@ -192,7 +192,7 @@ jest.mock("react-i18next", () => {
  * A stand-in ModelTable that records the model it was mounted over.
  *
  * It renders nothing on purpose. What this file needs from it is the single
- * fact that a table over UserEmail (or any of its six siblings) would be
+ * fact that a table over UserEmail (or any of its eight siblings) would be
  * visible here at all — the self-serve method components mount exactly those,
  * so "did the admin branch accidentally render the self-serve one?" is answered
  * by this list.
@@ -217,7 +217,9 @@ import TeamMember from "../../../Models/DatabaseModels/TeamMember";
 import User from "../../../Models/DatabaseModels/User";
 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";
@@ -238,7 +240,7 @@ const PROJECT_ID: ObjectID = new ObjectID(PROJECT_ID_STRING);
 const SIGNED_IN_USER_ID: ObjectID = new ObjectID(SIGNED_IN_USER_ID_STRING);
 
 /*
- * The seven models only their owner may read. Asserted as a SET because which
+ * The nine models only their owner may read. Asserted as a SET because which
  * one an admin surface reaches for hardly matters — every one carries a raw
  * identifier and most carry a credential.
  */
@@ -249,6 +251,8 @@ const NOTIFICATION_METHOD_MODELS: Array<unknown> = [
   UserPush,
   UserWhatsApp,
   UserTelegram,
+  UserSlack,
+  UserMicrosoftTeams,
   UserWebhook,
 ];
 
@@ -486,7 +490,7 @@ beforeEach((): void => {
     }
 
     /*
-     * Anything else, INCLUDING the seven method models this page must never ask
+     * Anything else, INCLUDING the nine method models this page must never ask
      * for. A non-empty answer would make a leak look like a feature working, so
      * the fallback stays empty and the assertion that matters is about the
      * request rather than the response.
@@ -570,7 +574,7 @@ describe("the list", () => {
     );
 
     /*
-     * The assertion is about the REQUEST, not the render. The seven models are
+     * The assertion is about the REQUEST, not the render. The nine models are
      * scoped to their owner, so a read here would be refused — but a component
      * that asks is already wrong, and the refusal is not something this page
      * may rely on.
@@ -657,10 +661,11 @@ describe("adding a method on somebody's behalf", () => {
 
     /*
      * Push is a device token minted at registration — there is nothing to type.
-     * Telegram needs the account holder to message the bot first. Webhook has
-     * no verification at all, so an admin-created one would be live the instant
-     * it was written, which is exactly the silent redirect this design rules
-     * out.
+     * Telegram needs the account holder to message the bot first. Slack and
+     * Microsoft Teams are born from the account holder's own OAuth workspace
+     * link, which nobody can establish for them. Webhook has no verification
+     * at all, so an admin-created one would be live the instant it was
+     * written, which is exactly the silent redirect this design rules out.
      */
     const modalText: string = document.body.textContent || "";
 
@@ -674,7 +679,13 @@ describe("adding a method on somebody's behalf", () => {
       return option.textContent || "";
     });
 
-    for (const forbidden of ["Push", "Telegram", "Webhook"]) {
+    for (const forbidden of [
+      "Push",
+      "Telegram",
+      "Slack",
+      "Microsoft Teams",
+      "Webhook",
+    ]) {
       expect(optionLabels).not.toContain(forbidden);
     }
   });

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

@@ -122,14 +122,18 @@ import CallMethods from "../../../../App/FeatureSet/Dashboard/src/Components/Not
 import PushMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/Push";
 import WhatsAppMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/WhatsApp";
 import TelegramMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/Telegram";
+import SlackMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/Slack";
+import MicrosoftTeamsMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/MicrosoftTeams";
 import WebhookMethods from "../../../../App/FeatureSet/Dashboard/src/Components/NotificationMethods/Webhook";
 import BaseModel, {
   DatabaseBaseModelType,
 } from "../../../Models/DatabaseModels/DatabaseBaseModel/DatabaseBaseModel";
 import UserCall from "../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../Models/DatabaseModels/UserNotificationRule";
 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";
@@ -1470,7 +1474,7 @@ describe("Escalation rules, wired: the delete confirmation says what it costs",
 
 /*
  * ---------------------------------------------------------------------------
- * THE SEVEN METHOD TABLES, RENDERED FOR REAL.
+ * THE NINE METHOD TABLES, RENDERED FOR REAL.
  * ---------------------------------------------------------------------------
  *
  * This block exists because the first cut of this feature shipped a correct,
@@ -1532,6 +1536,8 @@ const METHOD_ID_CALL: string = "33333333-9999-4999-8999-999999999999";
 const METHOD_ID_PUSH: string = "44444444-aaaa-4aaa-8aaa-aaaaaaaaaaaa";
 const METHOD_ID_WHATSAPP: string = "55555555-bbbb-4bbb-8bbb-bbbbbbbbbbbb";
 const METHOD_ID_TELEGRAM: string = "66666666-cccc-4ccc-8ccc-cccccccccccc";
+const METHOD_ID_SLACK: string = "88888888-eeee-4eee-8eee-eeeeeeeeeeee";
+const METHOD_ID_TEAMS: string = "99999999-ffff-4fff-8fff-ffffffffffff";
 const METHOD_ID_WEBHOOK: string = "77777777-dddd-4ddd-8ddd-dddddddddddd";
 
 const METHOD_SURFACES: Array<MethodSurface> = [
@@ -1624,6 +1630,36 @@ const METHOD_SURFACES: Array<MethodSurface> = [
     modalTitle: "Delete Telegram Account",
     methodLabel: "Telegram: @alexchen",
   },
+  {
+    name: "Slack",
+    Component: SlackMethods,
+    modelType: UserSlack,
+    relationName: "userSlack",
+    methodId: METHOD_ID_SLACK,
+    buildRow: (): BaseModel => {
+      return buildMethodRow(UserSlack, METHOD_ID_SLACK, {
+        slackUserName: "alexchen",
+        isVerified: true,
+      });
+    },
+    modalTitle: "Delete Slack Account",
+    methodLabel: "Slack: alexchen",
+  },
+  {
+    name: "Microsoft Teams",
+    Component: MicrosoftTeamsMethods,
+    modelType: UserMicrosoftTeams,
+    relationName: "userMicrosoftTeams",
+    methodId: METHOD_ID_TEAMS,
+    buildRow: (): BaseModel => {
+      return buildMethodRow(UserMicrosoftTeams, METHOD_ID_TEAMS, {
+        microsoftTeamsUserName: "Alex Example",
+        isVerified: true,
+      });
+    },
+    modalTitle: "Delete Microsoft Teams Account",
+    methodLabel: "Microsoft Teams: Alex Example",
+  },
   {
     name: "Webhook",
     Component: WebhookMethods,

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

@@ -38,7 +38,7 @@ import getJestMockFunction, { MockFunction } from "../../MockType";
  *
  * The fourth is where the "Notification Method" dropdown comes from, which is
  * now two different places depending on whose rules are on screen. For the
- * signed-in user it is still seven reads of the seven method models, and that
+ * signed-in user it is still nine reads of the nine method models, and that
  * path is the four settings pages every existing user relies on. For anybody
  * else those reads are REFUSED - the models are scoped to the person who owns
  * the device, because the columns behind them are the raw phone number, the
@@ -186,8 +186,10 @@ import AlertSeverity from "../../../Models/DatabaseModels/AlertSeverity";
 import IncidentSeverity from "../../../Models/DatabaseModels/IncidentSeverity";
 import UserCall from "../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../Models/DatabaseModels/UserNotificationRule";
 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";
@@ -199,7 +201,7 @@ import ObjectID from "../../../Types/ObjectID";
 import ProjectUtil from "../../../UI/Utils/Project";
 
 /*
- * The seven models whose rows only their owner may read. They are listed
+ * The nine models whose rows only their owner may read. They are listed
  * together because the assertion that matters is about the SET: an admin
  * surface that reads any one of them is reading a row it is not entitled to,
  * and which one hardly matters.
@@ -211,13 +213,15 @@ const NOTIFICATION_METHOD_MODELS: Array<unknown> = [
   UserPush,
   UserWhatsApp,
   UserTelegram,
+  UserSlack,
+  UserMicrosoftTeams,
   UserWebhook,
 ];
 
 /*
  * What the admin surface hands over in place of those reads: a channel name, the
  * id of the row, and a mask. Telegram is unverified on purpose - the self-serve
- * path filters `isVerified: true` in six of its seven queries, so a supplied
+ * path filters `isVerified: true` in eight of its nine queries, so a supplied
  * list that offered unverified methods would be the two paths disagreeing about
  * what is pickable.
  */
@@ -250,6 +254,8 @@ const METHOD_FOREIGN_KEYS: Array<keyof UserNotificationRule> = [
   "userPushId",
   "userWhatsAppId",
   "userTelegramId",
+  "userSlackId",
+  "userMicrosoftTeamsId",
   "userWebhookId",
 ];
 
@@ -343,7 +349,7 @@ const getMethodOptions: GetMethodOptions = (
 };
 
 /*
- * The seven RELATION spellings. Selecting any of these on a rule pulls columns
+ * The nine RELATION spellings. Selecting any of these on a rule pulls columns
  * out of the method models themselves - the raw address, the raw number, the
  * telegram handle - through a table an administrator is allowed to read.
  *
@@ -366,6 +372,8 @@ const METHOD_RELATIONS: Array<string> = [
   "userPush",
   "userWhatsApp",
   "userTelegram",
+  "userSlack",
+  "userMicrosoftTeams",
   "userWebhook",
 ];
 
@@ -719,7 +727,7 @@ describe("OnCallRulesTable", () => {
 
     /*
      * The whole point of the redesign, in one assertion. Not "reads them and
-     * shows fewer columns" - does not read them. Each of these seven models is
+     * shows fewer columns" - does not read them. Each of these nine models is
      * scoped to the person who owns the device, and the columns behind them are
      * the raw phone number, the webhook bearer url, the push device token, the
      * telegram chat id and the verification code. A request here is a request
@@ -748,7 +756,7 @@ describe("OnCallRulesTable", () => {
      * The readiness payload the admin page sources these from is fetched
      * asynchronously and can fail outright, so an absent list is a real state
      * rather than a caller mistake. Treating it as "then fetch them yourself"
-     * would fire seven refused requests and turn this component's error state on
+     * would fire nine refused requests and turn this component's error state on
      * - taking the rule repair away because a DIFFERENT read failed.
      */
     await renderForOtherUser(undefined);
@@ -786,7 +794,7 @@ describe("OnCallRulesTable", () => {
 
     /*
      * The unverified Telegram method is absent, which mirrors the
-     * `isVerified: true` filter on six of the seven self-serve queries. A rule
+     * `isVerified: true` filter on eight of the nine self-serve queries. A rule
      * pointed at an unverified device is a rule that pages nothing.
      */
     expect(
@@ -805,7 +813,7 @@ describe("OnCallRulesTable", () => {
       });
 
     /*
-     * The seven foreign keys are mutually exclusive and nothing validates that
+     * The nine foreign keys are mutually exclusive and nothing validates that
      * client-side, so this asserts the whole set: an SMS id written to
      * `userEmailId` would page an address rather than a phone, and would not
      * error anywhere on the way.
@@ -968,7 +976,7 @@ describe("OnCallRulesTable", () => {
   test("the signed-in user's own table still reads the method models itself", async () => {
     /*
      * The regression surface. Four settings pages every existing user already
-     * relies on read their own seven models to fill this dropdown, and reading
+     * relies on read their own nine models to fill this dropdown, and reading
      * your own rows is exactly what those models allow. Nothing about the admin
      * surface is a reason to change it - and an unmasked label is more use to
      * somebody looking at their own phone number than a mask of it.
@@ -985,7 +993,7 @@ describe("OnCallRulesTable", () => {
       getQueriedUserIds().filter((userId: string | undefined) => {
         return userId === CURRENT_USER_ID_STRING;
       }),
-    ).toHaveLength(7);
+    ).toHaveLength(9);
 
     expect(getMethodOptions(capturedTables[0]!)).toEqual([
       { label: `Email: ${OWN_EMAIL_ADDRESS}`, value: OWN_EMAIL_ID },

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

@@ -120,6 +120,23 @@ describe("Pay as you go notices", () => {
       expect(card).toHaveTextContent("Starting at");
     });
 
+    it("names security events among the pillars billed at the telemetry rate", () => {
+      /*
+       * Security events ingest on the same key and meter at the same
+       * $0.10/GB as the other telemetry pillars. This sentence is the body of
+       * the consent checkbox a user has to tick to create a key, so a pillar
+       * missing from it is a pillar the user is charged for without ever
+       * having been told.
+       */
+      render(<TelemetryPayAsYouGoCard />);
+
+      expect(
+        screen.getByTestId("telemetry-pay-as-you-go-card"),
+      ).toHaveTextContent(
+        "Logs, traces, metrics, profiles and security events are billed at",
+      );
+    });
+
     it("says the charge stops when the key is deleted, so the notice is not just a threat", () => {
       render(<TelemetryPayAsYouGoCard />);
 

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

@@ -117,6 +117,30 @@ const NOT_READABLE_BY_THEIR_DOMAIN_ROLES: Array<string> = [
   "IncomingCallPolicyEscalationRule",
 ];
 
+/*
+ * Columns inside an in-domain table whose read list deliberately stops short of
+ * the domain's full tier set, and why. The table-level list above is about
+ * whole tables a role holder is kept out of; this is the same idea one level
+ * down, for a table they are otherwise welcome in.
+ *
+ * Entries are the exact `<table>.<column> is missing <tier>` strings the sweep
+ * produces, so the list is self-policing: widen one of these read lists again
+ * and the entry stops being produced and the assertion fails.
+ *
+ * https://github.com/OneUptime/oneuptime/issues/3360 - Monitor's three secret
+ * keys are bearer credentials, not monitor data. Reading one is gated on being
+ * able to ROTATE it, which is what separates MonitorMember (may edit a monitor,
+ * so may see and reset its key) from MonitorViewer (read-only, so may not).
+ * Viewer used to be on these lists, which made "read-only" mean "can read a
+ * live credential for every agent in the project" -- the same reasoning that
+ * keeps MonitorSecret out of the table list above.
+ */
+const COLUMNS_NOT_READABLE_BY_THEIR_DOMAIN_ROLES: Array<string> = [
+  "Monitor.incomingEmailSecretKey is missing MonitorViewer",
+  "Monitor.incomingRequestSecretKey is missing MonitorViewer",
+  "Monitor.serverMonitorSecretKey is missing MonitorViewer",
+];
+
 type ModelNameFunction = (modelType: ModelType) => string;
 
 const modelName: ModelNameFunction = (modelType: ModelType): string => {
@@ -317,7 +341,9 @@ describe("Domain role tier coverage", () => {
       }
     }
 
-    expect(missing.sort()).toEqual([]);
+    expect(missing.sort()).toEqual(
+      COLUMNS_NOT_READABLE_BY_THEIR_DOMAIN_ROLES.slice().sort(),
+    );
     expect(checked).toBeGreaterThan(500);
   });
 });