@oneuptime/common 12.0.32 → 12.0.34

package/Server/Services/UserNotificationEmailRollupBatchService.ts

@@ -0,0 +1,78 @@
+import CreateBy from "../Types/Database/CreateBy";
+import DeleteBy from "../Types/Database/DeleteBy";
+import UpdateBy from "../Types/Database/UpdateBy";
+import { OnCreate, OnDelete, OnUpdate } from "../Types/Database/Hooks";
+import DatabaseService from "./DatabaseService";
+import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
+import { ROLLUP_BATCH_RETENTION_DAYS } from "../Utils/EmailRollup/EmailRollupConstants";
+import Model from "../../Models/DatabaseModels/UserNotificationEmailRollupBatch";
+import NotAuthorizedException from "../../Types/Exception/NotAuthorizedException";
+
+/*
+ * The rollup claim ledger. Root only in every direction: an insert here is
+ * what wins an epoch, so a caller who could create one could stop the next
+ * rollup being sent, and one who could delete one could make it be sent
+ * twice.
+ *
+ * Retention is set UNCONDITIONALLY, deliberately unlike EmailLogService,
+ * which only registers its retention when billing is enabled. The
+ * HardDelete:HardDeleteOlderItemsInDatabase cron iterates every service in
+ * the Services array with no billing check, so a gated call would simply
+ * never prune on a self-hosted install.
+ *
+ * Thirty days rather than the items' seven: a batch row is the record of how
+ * many notifications one email replaced, which is the number the whole
+ * feature is judged on, and it is one row per flush rather than one per
+ * notification. Pruning it cannot orphan anything, because rollupBatchId on
+ * the item table is deliberately a bare column with no foreign key.
+ */
+export class Service extends DatabaseService<Model> {
+  public constructor() {
+    super(Model);
+    this.hardDeleteItemsOlderThanInDays(
+      "createdAt",
+      ROLLUP_BATCH_RETENTION_DAYS,
+    );
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeCreate(
+    createBy: CreateBy<Model>,
+  ): Promise<OnCreate<Model>> {
+    if (!createBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup batches are claimed by the flush worker only.",
+      );
+    }
+
+    return { createBy, carryForward: null };
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeUpdate(
+    updateBy: UpdateBy<Model>,
+  ): Promise<OnUpdate<Model>> {
+    if (!updateBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup batches are claimed by the flush worker only.",
+      );
+    }
+
+    return { updateBy, carryForward: null };
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeDelete(
+    deleteBy: DeleteBy<Model>,
+  ): Promise<OnDelete<Model>> {
+    if (!deleteBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup batches are claimed by the flush worker only.",
+      );
+    }
+
+    return { deleteBy, carryForward: null };
+  }
+}
+
+export default new Service();

package/Server/Services/UserNotificationEmailRollupItemService.ts

@@ -0,0 +1,79 @@
+import CreateBy from "../Types/Database/CreateBy";
+import DeleteBy from "../Types/Database/DeleteBy";
+import UpdateBy from "../Types/Database/UpdateBy";
+import { OnCreate, OnDelete, OnUpdate } from "../Types/Database/Hooks";
+import DatabaseService from "./DatabaseService";
+import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
+import { ROLLUP_ITEM_RETENTION_DAYS } from "../Utils/EmailRollup/EmailRollupConstants";
+import Model from "../../Models/DatabaseModels/UserNotificationEmailRollupItem";
+import NotAuthorizedException from "../../Types/Exception/NotAuthorizedException";
+
+/*
+ * The owner-email rollup queue and volume ledger. Root only in every
+ * direction: a pending row is the thing that makes a deferred notification
+ * eventually arrive, so nothing outside the notification write path and the
+ * flush sweep may insert, edit or remove one.
+ *
+ * Retention is set UNCONDITIONALLY, deliberately unlike EmailLogService,
+ * which only registers its retention when billing is enabled. The
+ * HardDelete:HardDeleteOlderItemsInDatabase cron iterates every service in
+ * the Services array and honours whatever retention it declares, with no
+ * billing check anywhere in the loop - so gating the call on IsBillingEnabled
+ * would leave a self-hosted install accumulating one row per owner email
+ * forever, which for the exact customer this feature exists for is thousands
+ * of rows a day.
+ *
+ * Seven days is chosen against the two things that read the table: the burst
+ * counter, which looks back BURST_WINDOW_MINUTES, and a human answering "what
+ * flooded this inbox last week".
+ */
+export class Service extends DatabaseService<Model> {
+  public constructor() {
+    super(Model);
+    this.hardDeleteItemsOlderThanInDays(
+      "createdAt",
+      ROLLUP_ITEM_RETENTION_DAYS,
+    );
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeCreate(
+    createBy: CreateBy<Model>,
+  ): Promise<OnCreate<Model>> {
+    if (!createBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup items are written by the notification pipeline only.",
+      );
+    }
+
+    return { createBy, carryForward: null };
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeUpdate(
+    updateBy: UpdateBy<Model>,
+  ): Promise<OnUpdate<Model>> {
+    if (!updateBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup items are written by the notification pipeline only.",
+      );
+    }
+
+    return { updateBy, carryForward: null };
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeDelete(
+    deleteBy: DeleteBy<Model>,
+  ): Promise<OnDelete<Model>> {
+    if (!deleteBy.props.isRoot) {
+      throw new NotAuthorizedException(
+        "Notification email rollup items are written by the notification pipeline only.",
+      );
+    }
+
+    return { deleteBy, carryForward: null };
+  }
+}
+
+export default new Service();

package/Server/Services/UserNotificationEmailRollupSettingService.ts

@@ -0,0 +1,113 @@
+import DatabaseService from "./DatabaseService";
+import CreateBy from "../Types/Database/CreateBy";
+import { OnCreate } from "../Types/Database/Hooks";
+import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
+import Model from "../../Models/DatabaseModels/UserNotificationEmailRollupSetting";
+import BadDataException from "../../Types/Exception/BadDataException";
+import ObjectID from "../../Types/ObjectID";
+
+/*
+ * The escape hatch from owner-email burst rollup, one row per (user, project).
+ *
+ * The read below is the ONLY place the preference is consulted, and it is
+ * deliberately not cached. A cache would mean a person who has just clicked
+ * "send me every email immediately" keeps getting batched mail for the length
+ * of the TTL - which is precisely the complaint the toggle exists to answer,
+ * reproduced by the mechanism meant to serve it. The query is a single indexed
+ * row on a table with at most one row per project member, on a path that
+ * already runs a dozen queries, and the write path only reaches it when it is
+ * about to DEFER - never on the common below-the-threshold send.
+ */
+export class Service extends DatabaseService<Model> {
+  public constructor() {
+    super(Model);
+  }
+
+  /*
+   * True when this person's owner notification emails may be coalesced.
+   *
+   * Absent row means enabled. Rollup ships on by default with no backfill, so
+   * almost nobody has a row here; treating "no row" as anything other than the
+   * default would make the feature depend on data that does not exist.
+   *
+   * This does NOT swallow errors. The one caller reads it inside the write
+   * path's fail-open catch, which turns any failure into an immediate send -
+   * the same direction this method's `false` means, and the same direction
+   * every other failure in that path takes.
+   */
+  @CaptureSpan()
+  public async isRollupEnabledForUser(data: {
+    userId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<boolean> {
+    const setting: Model | null = await this.findOneBy({
+      query: {
+        userId: data.userId,
+        projectId: data.projectId,
+      },
+      select: {
+        isEnabled: true,
+      },
+      props: {
+        isRoot: true,
+      },
+    });
+
+    if (!setting) {
+      return true;
+    }
+
+    /*
+     * Only an explicit false opts out. A row whose isEnabled somehow arrived
+     * NULL - a hand-written insert, a column added ahead of its default - is
+     * not an opt-out, because opting somebody out of individual emails is the
+     * change that needs to have been asked for.
+     */
+    return setting.isEnabled !== false;
+  }
+
+  @CaptureSpan()
+  protected override async onBeforeCreate(
+    createBy: CreateBy<Model>,
+  ): Promise<OnCreate<Model>> {
+    if (!createBy.data.projectId) {
+      throw new BadDataException("projectId is required");
+    }
+
+    if (!createBy.data.userId) {
+      throw new BadDataException("userId is required");
+    }
+
+    /*
+     * One row per person per project. The page creates lazily on the first
+     * toggle, so a double click or two open tabs would otherwise leave two
+     * rows and make findOneBy's answer depend on which one it happened to
+     * pick. There is no unique index behind this check - the same
+     * check-then-create shape UserNotificationSettingService.onBeforeCreate
+     * already uses - so it narrows the window rather than closing it; the read
+     * above tolerates a duplicate because both rows say the same thing in
+     * every flow the UI can produce.
+     */
+    const existingCount: number = (
+      await this.countBy({
+        query: {
+          projectId: createBy.data.projectId,
+          userId: createBy.data.userId,
+        },
+        props: {
+          isRoot: true,
+        },
+      })
+    ).toNumber();
+
+    if (existingCount > 0) {
+      throw new BadDataException(
+        "An email rollup setting already exists for this user in this project.",
+      );
+    }
+
+    return { createBy, carryForward: null };
+  }
+}
+
+export default new Service();

package/Server/Services/UserNotificationSettingService.ts

@@ -3,7 +3,6 @@ import { OnCreate } from "../Types/Database/Hooks";
 import logger from "../Utils/Logger";
 import CallService from "./CallService";
 import DatabaseService from "./DatabaseService";
-import MailService from "./MailService";
 import ProjectCallSMSConfigService from "./ProjectCallSMSConfigService";
 import SmsService from "./SmsService";
 import TeamMemberService from "./TeamMemberService";
@@ -51,8 +50,11 @@ import {
   WorkspaceMessageBlock,
   WorkspacePayloadMarkdown,
 } from "../../Types/Workspace/WorkspaceMessagePayload";
+import EmailRollupWriter from "../Utils/EmailRollup/EmailRollupWriter";
 import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
 import { appendRecipientToWhatsAppMessage } from "../Utils/WhatsAppTemplateUtil";
+import DatabaseConfig from "../DatabaseConfig";
+import URL from "../../Types/API/URL";
 
 export class Service extends DatabaseService<UserNotificationSetting> {
   public constructor() {
@@ -76,6 +78,16 @@ export class Service extends DatabaseService<UserNotificationSetting> {
      */
     whatsAppMessage?: WhatsAppMessagePayload | undefined;
     telegramMessage?: TelegramMessagePayload | undefined;
+    /*
+     * Bypasses burst coalescing for this send, before any rollup bookkeeping
+     * runs. Some producers reuse another family's event type: the SLA-breach
+     * job at App/FeatureSet/Workers/Jobs/IncidentSla/CheckSlaBreaches.ts sends
+     * under EmailTemplateType.IncidentOwnerResourceCreated at :265 and reuses
+     * SEND_INCIDENT_CREATED_OWNER_NOTIFICATION at :286, so the event type
+     * alone cannot express that this particular message is urgent. Only a
+     * caller knows that, so only a caller can say so.
+     */
+    forceImmediate?: boolean | undefined;
     incidentId?: ObjectID | undefined;
     alertId?: ObjectID | undefined;
     alertEpisodeId?: ObjectID | undefined;
@@ -139,34 +151,87 @@ export class Service extends DatabaseService<UserNotificationSetting> {
           },
         });
 
+        const emailEnvelope: EmailEnvelope = {
+          ...data.emailEnvelope,
+          vars: { ...data.emailEnvelope.vars },
+        };
+
+        if (userEmails.length > 0) {
+          try {
+            const dashboardUrl: URL = await DatabaseConfig.getDashboardUrl();
+            /*
+             * Keep this out of the producer's envelope and the other channels.
+             * A *Link variable would be mistaken for a resource by the rollup writer.
+             */
+            emailEnvelope.vars["notificationPreferencesUrl"] = URL.fromString(
+              dashboardUrl.toString(),
+            )
+              .addRoute(
+                `/${data.projectId.toString()}/user-settings/notification-settings`,
+              )
+              .toString();
+          } catch (err) {
+            // The footer retains navigation instructions if a URL is unavailable.
+            logger.error(err);
+          }
+        }
+
         for (const userEmail of userEmails) {
-          MailService.sendMail(
-            {
-              ...data.emailEnvelope,
-              toEmail: userEmail.email!,
-            },
-            {
+          /*
+           * The one seam where an owner email can be held back. Below the
+           * burst threshold the email is sent immediately with its original
+           * subject, template and correlation ids, plus the preferences URL
+           * above. Delivery is fire-and-forget inside the writer; above the
+           * threshold the message is
+           * queued for a rollup instead of dropped. Awaited, unlike the raw
+           * send it replaces, because the queue row has to exist before this
+           * method returns; the writer itself never awaits MailService.
+           *
+           * The email-only envelope copy is never mutated by the writer.
+           * The original remains unchanged, which the Telegram fallback and Slack /
+           * Microsoft Teams bodies further down depend on: all three
+           * synthesise their message from data.emailEnvelope.subject.
+           *
+           * Guarded even though sendOrRollup is written not to throw. The send
+           * it replaces was fire-and-forget, so one bad address could never
+           * cost another address its email - let alone cost this notification
+           * its SMS, call, push, Telegram, workspace and webhook deliveries
+           * further down. Awaiting reintroduces that possibility; this catch
+           * takes it back out.
+           */
+          try {
+            await EmailRollupWriter.sendOrRollup({
               projectId: data.projectId,
-              incidentId: data.incidentId,
-              alertId: data.alertId,
-              alertEpisodeId: data.alertEpisodeId,
-              incidentEpisodeId: data.incidentEpisodeId,
-              monitorId: data.monitorId,
-              scheduledMaintenanceId: data.scheduledMaintenanceId,
-              statusPageId: data.statusPageId,
-              statusPageAnnouncementId: data.statusPageAnnouncementId,
               userId: data.userId,
-              teamId: data.teamId,
-              // OnCall-related fields
-              onCallPolicyId: data.onCallPolicyId,
-              onCallPolicyEscalationRuleId: data.onCallPolicyEscalationRuleId,
-              onCallDutyPolicyExecutionLogTimelineId:
-                data.onCallDutyPolicyExecutionLogTimelineId,
-              onCallScheduleId: data.onCallScheduleId,
-            },
-          ).catch((err: Error) => {
+              toEmail: userEmail.email!,
+              eventType: data.eventType,
+              emailEnvelope: emailEnvelope,
+              mailOptions: {
+                projectId: data.projectId,
+                incidentId: data.incidentId,
+                alertId: data.alertId,
+                alertEpisodeId: data.alertEpisodeId,
+                incidentEpisodeId: data.incidentEpisodeId,
+                monitorId: data.monitorId,
+                scheduledMaintenanceId: data.scheduledMaintenanceId,
+                statusPageId: data.statusPageId,
+                statusPageAnnouncementId: data.statusPageAnnouncementId,
+                userId: data.userId,
+                teamId: data.teamId,
+                // OnCall-related fields
+                onCallPolicyId: data.onCallPolicyId,
+                onCallPolicyEscalationRuleId: data.onCallPolicyEscalationRuleId,
+                onCallDutyPolicyExecutionLogTimelineId:
+                  data.onCallDutyPolicyExecutionLogTimelineId,
+                onCallScheduleId: data.onCallScheduleId,
+              },
+              ...(data.forceImmediate !== undefined && {
+                forceImmediate: data.forceImmediate,
+              }),
+            });
+          } catch (err) {
             logger.error(err);
-          });
+          }
         }
       }
 

package/Server/Services/UserService.ts

@@ -353,6 +353,13 @@ export class Service extends DatabaseService<Model> {
       carryForward = users;
     }
 
+    if (updateBy.data.email) {
+      await this.expirePasswordResetTokensForEmailChange({
+        newEmail: updateBy.data.email as Email,
+        existingUsers: carryForward,
+      });
+    }
+
     /*
      * There used to be a guard here refusing to set `enableTwoFactorAuth` on
      * an account with no verified authenticator, on the grounds that doing so
@@ -412,6 +419,94 @@ export class Service extends DatabaseService<Model> {
     return { updateBy, carryForward: carryForward };
   }
 
+  /**
+   * Kill any outstanding password-reset link for every account whose email
+   * address this update is about to change.
+   *
+   * A reset link is a bearer credential addressed to ONE mailbox: holding it
+   * proves only that somebody could read mail sent to the address the account
+   * had when the link was minted. Move the account to a different address and
+   * that proof is about a mailbox the account no longer uses, so the link has
+   * to die with the address it was sent to.
+   *
+   * Without this, changing your email is not the account-recovery step that
+   * users -- and our own "You have changed your email" mail -- take it to be:
+   *
+   *   1. An attacker who can read the victim's mailbox requests a password
+   *      reset and does NOT spend the link. Nothing about the account looks
+   *      wrong, because nothing has changed yet.
+   *   2. The victim notices the mailbox is compromised and moves the account
+   *      to an address the attacker cannot read. This is exactly the advice
+   *      they would be given, and they now believe they are safe.
+   *   3. The attacker spends the link from step 1. `/reset-password` finds the
+   *      row BY TOKEN HASH ALONE -- it never looks at the email address -- so
+   *      it happily sets a new password on the account at its NEW address, and
+   *      the victim is locked out of an account they had just rescued.
+   *
+   * Cleared BEFORE the email is written rather than afterwards in
+   * `onUpdateSuccess`, so there is no instant in which the new address is
+   * committed while a link mailed to the old one is still redeemable. The
+   * price of that ordering is that an email update which subsequently fails
+   * has still burned a pending link, and the user has to request another one.
+   * For a credential that is the right way round.
+   *
+   * Only rows whose address actually CHANGES are touched. Directory syncs
+   * rewrite `email` with the value it already has on every push (see
+   * `App/FeatureSet/Identity/API/SCIM.ts`, which updates whenever either the
+   * email or the name is present), and clearing on those would let an
+   * unrelated SCIM run invalidate a reset link the user is part-way through
+   * using.
+   *
+   * A row that came back with no `email` at all is treated as changed. That
+   * happens when the caller could not read the column, and on a credential the
+   * safe assumption is the one that expires the token.
+   *
+   * NOTE: this runs from `onBeforeUpdate`, so an email write made with
+   * `ignoreHooks: true` would slip past it. Nothing does that today -- the
+   * dashboard, the SCIM endpoints and the admin API all go through the hooks
+   * -- and any new caller that writes `email` hook-free has to clear these two
+   * columns itself.
+   */
+  @CaptureSpan()
+  private async expirePasswordResetTokensForEmailChange(data: {
+    newEmail: Email;
+    existingUsers: Array<Model>;
+  }): Promise<void> {
+    const newEmail: string = data.newEmail.toString().toLowerCase();
+
+    for (const user of data.existingUsers) {
+      if (!user.id) {
+        continue;
+      }
+
+      const currentEmail: string | undefined = user.email
+        ?.toString()
+        .toLowerCase();
+
+      if (currentEmail === newEmail) {
+        continue;
+      }
+
+      await this.updateOneById({
+        id: user.id,
+        data: {
+          resetPasswordToken: null!,
+          resetPasswordExpires: null!,
+        },
+        /*
+         * Root because `resetPasswordToken` is declared with `update: []` --
+         * no permission can write it -- and hook-free because this IS the
+         * update hook; re-entering it would have this write go looking for an
+         * email change of its own.
+         */
+        props: {
+          isRoot: true,
+          ignoreHooks: true,
+        },
+      });
+    }
+  }
+
   @CaptureSpan()
   protected override async onBeforeDelete(
     deleteBy: DeleteBy<Model>,