@oneuptime/common 14.0.6 → 14.0.8

package/Server/API/StatusPageSubscriberAPI.ts

@@ -1,6 +1,7 @@
 import StatusPageSubscriberService, {
   Service as StatusPageSubscriberServiceType,
 } from "../Services/StatusPageSubscriberService";
+import StatusPageService from "../Services/StatusPageService";
 import {
   ExpressRequest,
   ExpressResponse,
@@ -9,6 +10,15 @@ import {
 import Response from "../Utils/Response";
 import BaseAPI from "./BaseAPI";
 import StatusPageSubscriber from "../../Models/DatabaseModels/StatusPageSubscriber";
+import ObjectID from "../../Types/ObjectID";
+import StatusPageSubscriberUnsubscribe from "../../Types/StatusPage/StatusPageSubscriberUnsubscribe";
+
+/*
+ * What the old unsubscribe route answers for an id that is not a
+ * subscriber's. Static, so nothing from the request is ever echoed into it.
+ */
+export const OUT_OF_DATE_UNSUBSCRIBE_LINK_HTML: string =
+  '<!DOCTYPE html><html lang="en"><head><meta charset="utf-8" /><meta name="robots" content="noindex" /><meta name="referrer" content="no-referrer" /><title>Unsubscribe link out of date</title></head><body><p>This unsubscribe link is out of date. To unsubscribe, use the unsubscribe link at the bottom of a recent message from the status page.</p></body></html>';
 
 export default class StatusPageSubscriberAPI extends BaseAPI<
   StatusPageSubscriber,
@@ -17,27 +27,65 @@ export default class StatusPageSubscriberAPI extends BaseAPI<
   public constructor() {
     super(StatusPageSubscriber, StatusPageSubscriberService);
 
+    /*
+     * The unsubscribe link notifications carried until the end of 2023:
+     * /api/status-page-subscriber/unsubscribe/{subscriberId}. It used to
+     * unsubscribe on the GET itself, knowing only the id - so a mail scanner
+     * fetching the link, or an <img> pointed at it from anywhere, cancelled
+     * the subscription.
+     *
+     * It no longer changes anything. An old link still leads somewhere
+     * useful: the status page's unsubscribe page, told only the id, which
+     * says the link is out of date and to use the one in a recent message
+     * (and, on a public page, offers the subscriber's manage page). It never
+     * hands out the subscriber's unsubscribe token - that would make the id
+     * alone enough to unsubscribe again. Notifications now carry
+     * {statusPageUrl}/unsubscribe/{id}-{token}, which asks before it acts.
+     */
     this.router.get(
       `${new this.entityType().getCrudApiPath()?.toString()}/unsubscribe/:id`,
       async (req: ExpressRequest, res: ExpressResponse, next: NextFunction) => {
         try {
-          await this.service.updateOneBy({
-            query: {
-              _id: req.params["id"] as string,
-            },
-            data: {
-              isUnsubscribed: true,
-            },
-            props: {
-              isRoot: true,
-              ignoreHooks: true,
-            },
-          });
-
-          return Response.sendHtmlResponse(
+          const subscriberId: string = (req.params["id"] as string) || "";
+
+          const subscriber: StatusPageSubscriber | null = ObjectID.isValidUUID(
+            subscriberId,
+          )
+            ? await this.service.findOneBy({
+                query: {
+                  _id: subscriberId,
+                },
+                select: {
+                  _id: true,
+                  statusPageId: true,
+                },
+                props: {
+                  isRoot: true,
+                  ignoreHooks: true,
+                },
+              })
+            : null;
+
+          Response.setNoCacheHeaders(res);
+
+          if (!subscriber || !subscriber.id || !subscriber.statusPageId) {
+            res.status(404);
+            res.setHeader("Content-Type", "text/html; charset=utf-8");
+            res.send(OUT_OF_DATE_UNSUBSCRIBE_LINK_HTML);
+            return;
+          }
+
+          const statusPageUrl: string =
+            await StatusPageService.getStatusPageURL(subscriber.statusPageId);
+
+          return Response.redirect(
             req,
             res,
-            "<html><body><p> You have been unsubscribed.</p><body><html>",
+            StatusPageSubscriberUnsubscribe.buildLink({
+              statusPageUrl: statusPageUrl,
+              subscriberId: subscriber.id,
+              unsubscribeToken: null,
+            }),
           );
         } catch (err) {
           next(err);

package/Server/Infrastructure/Postgres/SchemaMigrations/1795200000000-AddInventoryItemProjectEntityKeyIndex.ts

@@ -0,0 +1,217 @@
+import logger from "../../../Utils/Logger";
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+export const INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX: string =
+  "IDX_INVENTORY_ITEM_PROJECT_ENTITY_KEY";
+
+/*
+ * Above this many InventoryItem rows the index is not built here (see
+ * "LOCKING" below). Roughly ten seconds of build on modest hardware.
+ */
+export const INVENTORY_ITEM_INLINE_INDEX_BUILD_MAX_ROWS: number = 1_000_000;
+
+/* What an operator runs to build the index online, under exactly this name. */
+export const INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX_RUNBOOK: string = `CREATE INDEX CONCURRENTLY IF NOT EXISTS "${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX}" ON "InventoryItem" ("projectId", "entityKey")`;
+
+/*
+ * Adds ("projectId", "entityKey") on InventoryItem.
+ *
+ * WHY
+ *
+ * Relationships name both ends by entity key only. The Topology API resolves
+ * those keys to items constantly — the things services call, where they run,
+ * the other end of every row in the detail drawer — and the only index that
+ * leads with the key today is the unique ("projectId", "entityType",
+ * "entityKey"), which a type-less lookup can use only as one probe per type in
+ * the project. The queries are written to stay correct and acceptable without
+ * this index (they constrain "entityType" to the project's types so the
+ * unique index is usable), because on Helm installs migrations run
+ * asynchronously and the new API can serve traffic before this has been
+ * built. This makes the same lookups one probe.
+ *
+ * Relationships get no new index on purpose: InventoryItemRelationship is the
+ * largest inventory table and a plain CREATE INDEX would block its ingest
+ * writes for the whole build.
+ *
+ * WHY THIS IS HAND-WRITTEN
+ *
+ * A generated migration cannot bound its own lock wait or runtime, nor decide
+ * to leave a build to the operator, and this one runs against a table that
+ * ingest writes continuously. The entity declares the index by name with
+ * `synchronize: false` (see Types/Database/UnsynchronizedIndex.ts), so the
+ * schema builder neither generates a second copy nor drops this one.
+ *
+ * LOCKING, AND THE RUNBOOK FOR LARGE INSTALLS
+ *
+ * Migrations run one transaction each (migrationsTransactionMode "each"), so
+ * CREATE INDEX CONCURRENTLY is not available here. A plain CREATE INDEX holds
+ * a SHARE lock on InventoryItem for as long as the build takes: reads
+ * continue, inventory writes queue behind it and fail once their own
+ * lock_timeout (3 s in the app) or statement_timeout runs out.
+ *
+ * The build cannot be given more time than the connection allows. The
+ * effective ceiling is the client-side DATABASE_QUERY_TIMEOUT_MS of
+ * node-postgres (35 s by default), which no SET can raise: past it the client
+ * abandons the query — and the ROLLBACK queued behind it — while the server
+ * keeps building and keeps the lock. So statement_timeout stays at the
+ * connection's own value (30 s by default, below that ceiling; `DEFAULT`
+ * undoes anything an earlier statement on the session may have set), which
+ * makes Postgres cancel an overlong build itself and release the lock at
+ * once. `lock_timeout` stops the migration from queueing behind a long
+ * transaction (and parking every writer behind itself) for more than five
+ * seconds; a timeout fails the migration, which the next start retries.
+ *
+ * A build that would not finish comfortably inside that window is not
+ * attempted: when InventoryItem holds more than
+ * INVENTORY_ITEM_INLINE_INDEX_BUILD_MAX_ROWS rows (the planner's estimate
+ * from pg_class; a bounded count when the table has never been analyzed),
+ * this migration logs a warning and completes without the index. The
+ * Topology API is correct without it, only slower on key lookups. Such an
+ * install should build the index online, at any time, under exactly this
+ * name:
+ *
+ *   CREATE INDEX CONCURRENTLY IF NOT EXISTS "IDX_INVENTORY_ITEM_PROJECT_ENTITY_KEY"
+ *     ON "InventoryItem" ("projectId", "entityKey");
+ *
+ * Built before the upgrade, this migration finds it and does nothing. A
+ * CONCURRENTLY build that failed leaves an INVALID index behind under that
+ * name, which IF NOT EXISTS would otherwise accept forever; such a leftover
+ * is dropped here first (so the runbook works as written afterwards) and
+ * rebuilt when the table is small enough.
+ *
+ * An online build that is still RUNNING looks exactly like that leftover
+ * (pg_index.indisvalid is false until it finishes). Dropping it would queue
+ * for an ACCESS EXCLUSIVE lock behind the build and stall every reader and
+ * writer of InventoryItem meanwhile, so a build in progress
+ * (pg_stat_progress_create_index) is left to finish and this migration
+ * completes without touching it.
+ */
+export class AddInventoryItemProjectEntityKeyIndex1795200000000
+  implements MigrationInterface
+{
+  public name: string = "AddInventoryItemProjectEntityKeyIndex1795200000000";
+
+  /* Lowered only by tests; TypeORM constructs migrations without arguments. */
+  public constructor(
+    private maxRowsForInlineBuild: number = INVENTORY_ITEM_INLINE_INDEX_BUILD_MAX_ROWS,
+  ) {}
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(`SET LOCAL statement_timeout = DEFAULT`);
+    await queryRunner.query(`SET LOCAL lock_timeout = '5s'`);
+
+    const existing: Array<{ isValid: boolean }> = await queryRunner.query(
+      `SELECT x.indisvalid AS "isValid" FROM pg_index x
+       JOIN pg_class c ON c.oid = x.indexrelid
+       JOIN pg_namespace n ON n.oid = c.relnamespace
+       WHERE c.relname = $1 AND n.nspname = current_schema()`,
+      [INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX],
+    );
+
+    if (
+      existing.some((index: { isValid: boolean }): boolean => {
+        return index.isValid === true;
+      })
+    ) {
+      /* Pre-built by an operator (or already migrated): nothing to do. */
+      return;
+    }
+
+    if (existing.length > 0) {
+      if (await this.isBuildInProgress(queryRunner)) {
+        logger.warn(
+          `AddInventoryItemProjectEntityKeyIndex: an online build of ${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX} is in progress; leaving it to finish. If that build fails, drop the INVALID index it leaves behind and run again: ${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX_RUNBOOK};`,
+        );
+        return;
+      }
+      await queryRunner.query(
+        `DROP INDEX IF EXISTS "${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX}"`,
+      );
+    }
+
+    const rows: number = await this.estimateRows(queryRunner);
+
+    if (rows > this.maxRowsForInlineBuild) {
+      logger.warn(
+        `AddInventoryItemProjectEntityKeyIndex: InventoryItem holds about ${Math.round(
+          rows,
+        )} rows, more than the ${this.maxRowsForInlineBuild} this migration builds an index over while it blocks inventory writes, so the index ${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX} was NOT created. The Topology maps work without it but resolve entity keys more slowly. Build it online (it does not block writes) by running on the OneUptime database: ${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX_RUNBOOK};`,
+      );
+      return;
+    }
+
+    await queryRunner.query(
+      `CREATE INDEX IF NOT EXISTS "${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX}" ON "InventoryItem" ("projectId", "entityKey")`,
+    );
+  }
+
+  public async down(queryRunner: QueryRunner): Promise<void> {
+    /*
+     * DROP INDEX takes ACCESS EXCLUSIVE on the table; waiting for it would
+     * park every reader and writer of InventoryItem behind this statement.
+     */
+    await queryRunner.query(`SET LOCAL statement_timeout = DEFAULT`);
+    await queryRunner.query(`SET LOCAL lock_timeout = '5s'`);
+    await queryRunner.query(
+      `DROP INDEX IF EXISTS "${INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX}"`,
+    );
+  }
+
+  /* Whether a CREATE INDEX (CONCURRENTLY) of this index is running now. */
+  private async isBuildInProgress(queryRunner: QueryRunner): Promise<boolean> {
+    const builds: Array<unknown> = await queryRunner.query(
+      `SELECT 1 FROM pg_stat_progress_create_index p
+       JOIN pg_class c ON c.oid = p.index_relid
+       JOIN pg_namespace n ON n.oid = c.relnamespace
+       WHERE c.relname = $1 AND n.nspname = current_schema()`,
+      [INVENTORY_ITEM_PROJECT_ENTITY_KEY_INDEX],
+    );
+    return builds.length > 0;
+  }
+
+  /*
+   * How many rows InventoryItem holds, from the statistics the planner uses:
+   * pg_class.reltuples scaled from the pages it was measured over to the
+   * table's current size (so growth since the last ANALYZE counts). A table
+   * that has never been analyzed (reltuples -1), or whose statistics saw no
+   * pages although it has some now, is counted instead — only up to just past
+   * the threshold, so the count stays cheap on any table.
+   */
+  private async estimateRows(queryRunner: QueryRunner): Promise<number> {
+    const statistics: Array<{
+      reltuples: number | string | null;
+      relpages: number | string | null;
+      pages: number | string | null;
+    }> = await queryRunner.query(
+      `SELECT c.reltuples::float8 AS "reltuples", c.relpages::float8 AS "relpages",
+         (pg_relation_size(c.oid) / current_setting('block_size')::int)::float8 AS "pages"
+       FROM pg_class c
+       JOIN pg_namespace n ON n.oid = c.relnamespace
+       WHERE c.relname = 'InventoryItem' AND n.nspname = current_schema()`,
+    );
+
+    const reltuples: number = Number(statistics[0]?.reltuples ?? -1);
+    const relpages: number = Number(statistics[0]?.relpages ?? 0);
+    const pages: number = Number(statistics[0]?.pages ?? 0);
+
+    const isKnown: boolean =
+      Number.isFinite(reltuples) &&
+      reltuples >= 0 &&
+      Number.isFinite(relpages) &&
+      Number.isFinite(pages) &&
+      (relpages > 0 || pages === 0);
+
+    if (isKnown) {
+      return relpages > 0
+        ? Math.max(reltuples, (reltuples / relpages) * pages)
+        : reltuples;
+    }
+
+    const counted: Array<{ count: number | string }> = await queryRunner.query(
+      `SELECT COUNT(*)::int AS "count" FROM (SELECT 1 FROM "InventoryItem" LIMIT $1) bounded`,
+      [this.maxRowsForInlineBuild + 1],
+    );
+
+    return Number(counted[0]?.count ?? 0);
+  }
+}

package/Server/Infrastructure/Postgres/SchemaMigrations/1795300000000-SkipHiddenIncidentCreatedNotifications.ts

@@ -0,0 +1,49 @@
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+/*
+ * Data fix: settle the 'incident created' subscriber notification of hidden
+ * incidents that the worker left InProgress.
+ *
+ * Incident:SendNotificationToSubscribers used to mark an incident's 'created'
+ * notification InProgress and then, when the incident was not visible on
+ * status pages, move on without settling it. The job only ever picks up
+ * Pending rows, so those rows stayed InProgress forever: the dashboard showed
+ * "Notifications Being Sent" for good, and nothing could ever send them once
+ * the incident was published. The worker now marks them Skipped with a
+ * reason, and publishing such an incident can re-queue the notification (see
+ * IncidentCreatedRenotify) - but only from Skipped. This moves the rows the old
+ * worker stranded to the same Skipped state and reason, so they get that
+ * option too.
+ *
+ * Only hidden incidents are touched. `IS NOT TRUE` also covers a NULL
+ * visibility, which the worker treated as hidden. A visible incident that is
+ * InProgress may really be sending right now, and is left alone.
+ *
+ * The message is written out rather than imported so the migration keeps
+ * doing what it did when it shipped. It matches
+ * IncidentCreatedRenotify.hiddenFromStatusPagesMessage, which is what the
+ * worker writes, so migrated rows read exactly like newly skipped ones (a
+ * test pins the two together).
+ *
+ * down() restores nothing: putting rows back into a state that nothing ever
+ * leaves would only break them again.
+ */
+export const HIDDEN_FROM_STATUS_PAGES_MESSAGE: string =
+  "Incident is not visible on status pages. Skipping notifications to subscribers.";
+
+export class SkipHiddenIncidentCreatedNotifications1795300000000
+  implements MigrationInterface
+{
+  public name: string = "SkipHiddenIncidentCreatedNotifications1795300000000";
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `UPDATE "Incident" SET "subscriberNotificationStatusOnIncidentCreated" = 'Skipped', "subscriberNotificationStatusMessage" = $1 WHERE "subscriberNotificationStatusOnIncidentCreated" = 'InProgress' AND "isVisibleOnStatusPage" IS NOT TRUE`,
+      [HIDDEN_FROM_STATUS_PAGES_MESSAGE],
+    );
+  }
+
+  public async down(_queryRunner: QueryRunner): Promise<void> {
+    // Nothing to restore; see the note above.
+  }
+}

package/Server/Infrastructure/Postgres/SchemaMigrations/1795400000000-AddIncidentStatusPageScope.ts

@@ -0,0 +1,108 @@
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+/*
+ * Per-incident status page scope (Incident.statusPages).
+ *
+ * - IncidentStatusPage: the status pages an incident is limited to. Its join
+ *   rows cascade when either side is deleted.
+ * - Incident.isScopedToStatusPages: whether the incident is limited to its
+ *   status pages, so the status page queries can split on it in SQL. Existing
+ *   incidents are unscoped, which is today's behaviour, so the default needs
+ *   no backfill. It is never recomputed when join rows cascade away: an
+ *   incident whose only scoped page is deleted stays scoped - to nothing - and
+ *   is hidden rather than widened to every page its monitors reach. It is not
+ *   indexed: false on nearly every row, and an index built here would hold
+ *   this transaction's lock on Incident, reads included, for the whole build.
+ *   Adding the NOT NULL DEFAULT false column itself does not rewrite the
+ *   table.
+ * - Incident.statusPagesNotifiedOnCreation: the pages already sent the
+ *   incident's 'created' notification, so a page added later is told once.
+ * - IncidentTemplateStatusPage: the scope an incident template applies.
+ * - StatusPage.onlyShowScopedIncidents: pages that never show or notify an
+ *   unscoped incident. Off for every existing page.
+ */
+export class AddIncidentStatusPageScope1795400000000
+  implements MigrationInterface
+{
+  public name: string = "AddIncidentStatusPageScope1795400000000";
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `CREATE TABLE "IncidentStatusPage" ("incidentId" uuid NOT NULL, "statusPageId" uuid NOT NULL, CONSTRAINT "PK_704cbe88e7fbb614b8276db4326" PRIMARY KEY ("incidentId", "statusPageId"))`,
+    );
+    await queryRunner.query(
+      `CREATE INDEX "IDX_a4ad6eb224d14cc17708420961" ON "IncidentStatusPage" ("incidentId") `,
+    );
+    await queryRunner.query(
+      `CREATE INDEX "IDX_12a8bd395d53349410e5fce974" ON "IncidentStatusPage" ("statusPageId") `,
+    );
+    await queryRunner.query(
+      `CREATE TABLE "IncidentTemplateStatusPage" ("incidentTemplateId" uuid NOT NULL, "statusPageId" uuid NOT NULL, CONSTRAINT "PK_24de18b6b85dd0baf4e0016a807" PRIMARY KEY ("incidentTemplateId", "statusPageId"))`,
+    );
+    await queryRunner.query(
+      `CREATE INDEX "IDX_20db51def3a2086a8bf62294a1" ON "IncidentTemplateStatusPage" ("incidentTemplateId") `,
+    );
+    await queryRunner.query(
+      `CREATE INDEX "IDX_b1a0dee8efae60ea4a0c37f6b8" ON "IncidentTemplateStatusPage" ("statusPageId") `,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "StatusPage" ADD "onlyShowScopedIncidents" boolean NOT NULL DEFAULT false`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "Incident" ADD "isScopedToStatusPages" boolean NOT NULL DEFAULT false`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "Incident" ADD "statusPagesNotifiedOnCreation" jsonb`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentStatusPage" ADD CONSTRAINT "FK_a4ad6eb224d14cc177084209619" FOREIGN KEY ("incidentId") REFERENCES "Incident"("_id") ON DELETE CASCADE ON UPDATE CASCADE`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentStatusPage" ADD CONSTRAINT "FK_12a8bd395d53349410e5fce9743" FOREIGN KEY ("statusPageId") REFERENCES "StatusPage"("_id") ON DELETE CASCADE ON UPDATE CASCADE`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplateStatusPage" ADD CONSTRAINT "FK_20db51def3a2086a8bf62294a1f" FOREIGN KEY ("incidentTemplateId") REFERENCES "IncidentTemplate"("_id") ON DELETE CASCADE ON UPDATE CASCADE`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplateStatusPage" ADD CONSTRAINT "FK_b1a0dee8efae60ea4a0c37f6b81" FOREIGN KEY ("statusPageId") REFERENCES "StatusPage"("_id") ON DELETE CASCADE ON UPDATE CASCADE`,
+    );
+  }
+
+  public async down(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplateStatusPage" DROP CONSTRAINT "FK_b1a0dee8efae60ea4a0c37f6b81"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplateStatusPage" DROP CONSTRAINT "FK_20db51def3a2086a8bf62294a1f"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentStatusPage" DROP CONSTRAINT "FK_12a8bd395d53349410e5fce9743"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "IncidentStatusPage" DROP CONSTRAINT "FK_a4ad6eb224d14cc177084209619"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "Incident" DROP COLUMN "statusPagesNotifiedOnCreation"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "Incident" DROP COLUMN "isScopedToStatusPages"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "StatusPage" DROP COLUMN "onlyShowScopedIncidents"`,
+    );
+    await queryRunner.query(
+      `DROP INDEX "public"."IDX_b1a0dee8efae60ea4a0c37f6b8"`,
+    );
+    await queryRunner.query(
+      `DROP INDEX "public"."IDX_20db51def3a2086a8bf62294a1"`,
+    );
+    await queryRunner.query(`DROP TABLE "IncidentTemplateStatusPage"`);
+    await queryRunner.query(
+      `DROP INDEX "public"."IDX_12a8bd395d53349410e5fce974"`,
+    );
+    await queryRunner.query(
+      `DROP INDEX "public"."IDX_a4ad6eb224d14cc17708420961"`,
+    );
+    await queryRunner.query(`DROP TABLE "IncidentStatusPage"`);
+  }
+}

package/Server/Infrastructure/Postgres/SchemaMigrations/1795500000000-AddIncidentTemplateStatusPageScopeFlag.ts

@@ -0,0 +1,33 @@
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+/*
+ * IncidentTemplate.isScopedToStatusPages: whether a template limits the
+ * incidents declared from it to status pages, kept apart from its list of
+ * pages so that a template whose every page was deleted (the join rows
+ * cascade away) does not start declaring incidents that reach every status
+ * page (see the column in IncidentTemplate).
+ *
+ * Templates that already list status pages are scoped, so the flag is set for
+ * them. Nothing else changes: a template with no pages stays unscoped.
+ */
+export class AddIncidentTemplateStatusPageScopeFlag1795500000000
+  implements MigrationInterface
+{
+  public name: string = "AddIncidentTemplateStatusPageScopeFlag1795500000000";
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplate" ADD "isScopedToStatusPages" boolean NOT NULL DEFAULT false`,
+    );
+
+    await queryRunner.query(
+      `UPDATE "IncidentTemplate" SET "isScopedToStatusPages" = true WHERE "_id" IN (SELECT "incidentTemplateId" FROM "IncidentTemplateStatusPage")`,
+    );
+  }
+
+  public async down(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "IncidentTemplate" DROP COLUMN "isScopedToStatusPages"`,
+    );
+  }
+}

package/Server/Infrastructure/Postgres/SchemaMigrations/1795600000000-AddStatusPageSubscriberUnsubscribeToken.ts

@@ -0,0 +1,51 @@
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+/*
+ * Unsubscribing without signing in (StatusPageSubscriber.unsubscribeToken,
+ * StatusPageSubscriber.unsubscribedAt).
+ *
+ * - unsubscribeToken: the random secret in each subscriber's unsubscribe
+ *   link, {statusPageUrl}/unsubscribe/{id}-{token}. Holding the link is what
+ *   lets a subscriber of a private status page unsubscribe without an account
+ *   on it. New subscribers get one from StatusPageSubscriberService.
+ * - unsubscribedAt: when a subscription was cancelled. Subscriptions
+ *   cancelled before this column existed have none - there is no record of
+ *   when they were - and are left empty rather than given a made-up date.
+ *
+ * Only the two nullable columns, which Postgres adds without rewriting the
+ * table. Existing subscribers are given their tokens by the
+ * BackfillStatusPageSubscriberUnsubscribeTokens data migration, in batches
+ * and outside this migration's transaction: one UPDATE of every row here
+ * would hold ADD COLUMN's exclusive lock on the table - blocking every
+ * notification, subscribe and subscriber list - for as long as it took, and
+ * on a large table it would run into the connection's statement timeout and
+ * fail the deploy. Until the backfill reaches a subscriber, the first sender
+ * to need its link gives it one (StatusPageSubscriberService
+ * .ensureUnsubscribeTokens).
+ *
+ * down() drops both columns; the tokens cannot be recovered afterwards, and
+ * every link already sent stops working.
+ */
+export class AddStatusPageSubscriberUnsubscribeToken1795600000000
+  implements MigrationInterface
+{
+  public name: string = "AddStatusPageSubscriberUnsubscribeToken1795600000000";
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" ADD "unsubscribedAt" TIMESTAMP WITH TIME ZONE`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" ADD "unsubscribeToken" character varying(100)`,
+    );
+  }
+
+  public async down(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" DROP COLUMN "unsubscribeToken"`,
+    );
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" DROP COLUMN "unsubscribedAt"`,
+    );
+  }
+}

package/Server/Infrastructure/Postgres/SchemaMigrations/1795700000000-AddStatusPageSubscriberIsAddedByTeam.ts

@@ -0,0 +1,33 @@
+import { MigrationInterface, QueryRunner } from "typeorm";
+
+/*
+ * StatusPageSubscriber.isAddedByTeam: whether the status page's team added a
+ * subscriber (from the dashboard, with an API key or by a workflow) rather
+ * than the subscriber signing up on the status page. It decides whether the
+ * page's owners are told when the subscriber unsubscribes itself - Created
+ * By cannot, because an API key's or a workflow's create carries no user.
+ *
+ * Postgres 11 and later add a NOT NULL column with a constant default without
+ * rewriting the table. Subscribers that already exist are marked from Created
+ * By by the BackfillStatusPageSubscriberUnsubscribeTokens data migration, in
+ * batches outside this transaction (see
+ * 1795600000000-AddStatusPageSubscriberUnsubscribeToken for why); until it
+ * reaches one, StatusPageSubscriberService reads Created By as well.
+ */
+export class AddStatusPageSubscriberIsAddedByTeam1795700000000
+  implements MigrationInterface
+{
+  public name: string = "AddStatusPageSubscriberIsAddedByTeam1795700000000";
+
+  public async up(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" ADD "isAddedByTeam" boolean NOT NULL DEFAULT false`,
+    );
+  }
+
+  public async down(queryRunner: QueryRunner): Promise<void> {
+    await queryRunner.query(
+      `ALTER TABLE "StatusPageSubscriber" DROP COLUMN "isAddedByTeam"`,
+    );
+  }
+}