@bygghammar/cms-platform 0.91.1 → 0.92.0

package/scripts/review-fingerprint.sql

@@ -0,0 +1,43 @@
+-- The fingerprint of everything either publication reader looks at.
+--
+-- Read by scripts/cms-review.mjs before an upgrade and digested there, in
+-- TypeScript, because a reviewer stands at a database that does not have
+-- contract v3 yet and so has no cms_digest() to call. The migration recomputes
+-- the same object with the same expression, digests it with cms_digest(), and
+-- refuses if the two differ -- so this file and the block in
+-- 20260905120000_da2db0b2-6048-4aa8-8e4f-13ee33e9cc24.sql must stay one query.
+-- ops/migration-smoke.mjs is what holds them together: it builds an approval
+-- from this text and applies the real migration against it, and a drift on
+-- either side comes back as "the pages changed after this review was approved".
+--
+-- Soft-deleted pages and inactive publication rows are in here on purpose.
+-- Deleting a page and deactivating a row both change what the site serves, and
+-- both would otherwise slip through a fingerprint that only looked at what is
+-- live.
+SELECT jsonb_build_object(
+         'pageCount', count(*),
+         'pages', coalesce(jsonb_agg(entry ORDER BY page_id), '[]'::jsonb)
+       )::text
+  FROM (
+    SELECT pg.id AS page_id,
+           jsonb_build_object(
+             'id', pg.id::text,
+             'key', pg.key,
+             'status', pg.status,
+             'currentVersionId', pg.current_version_id::text,
+             'deletedAt', to_char(pg.deleted_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+             'publications', (
+               SELECT coalesce(jsonb_agg(jsonb_build_object(
+                        'id', pp.id::text,
+                        'versionId', pp.version_id::text,
+                        'publishAt', to_char(pp.publish_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+                        'unpublishAt', to_char(pp.unpublish_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+                        'publishedAt', to_char(pp.published_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+                        'active', pp.is_active
+                      ) ORDER BY pp.id), '[]'::jsonb)
+                 FROM public.page_publications pp
+                WHERE pp.page_id = pg.id
+             )
+           ) AS entry
+      FROM public.pages pg
+  ) snapshot;

package/scripts/review-scan.sql

@@ -0,0 +1,56 @@
+-- What the classifier needs to see, and nothing else.
+--
+-- Active publication rows for live pages, plus the owning page of every version
+-- either reader could reach. classifyPage() in src/platform/publication-review.ts
+-- reads exactly this shape; the migration reads the same rows through its own
+-- CTE chain. Restricted to referenced versions rather than every version ever
+-- written, because the only question asked of the map is "does this id exist,
+-- and is it this page's" -- an id that is missing from a restricted map is
+-- missing in the same way it would be from a complete one.
+--
+-- Ordered by key so a scan of an unchanged database reads the same twice.
+SELECT jsonb_build_object(
+         'pages', (
+           SELECT coalesce(jsonb_agg(jsonb_build_object(
+                    'pageId', p.id::text,
+                    'pageKey', p.key,
+                    'status', p.status,
+                    'currentVersionId', p.current_version_id::text,
+                    'publications', (
+                      SELECT coalesce(jsonb_agg(jsonb_build_object(
+                               'id', pp.id::text,
+                               'versionId', pp.version_id::text,
+                               'publishAt', to_char(pp.publish_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+                               'unpublishAt', to_char(pp.unpublish_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"'),
+                               'publishedAt', to_char(pp.published_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.MS"Z"')
+                             ) ORDER BY pp.id), '[]'::jsonb)
+                        FROM public.page_publications pp
+                       WHERE pp.page_id = p.id AND pp.is_active
+                    )
+                  ) ORDER BY p.key), '[]'::jsonb)
+             FROM public.pages p
+            WHERE p.deleted_at IS NULL
+         ),
+         'versionOwners', (
+           SELECT coalesce(jsonb_object_agg(v.id::text, v.page_id::text), '{}'::jsonb)
+             FROM public.page_versions v
+            WHERE v.id IN (
+                    SELECT current_version_id FROM public.pages WHERE current_version_id IS NOT NULL
+                    UNION
+                    SELECT version_id FROM public.page_publications WHERE version_id IS NOT NULL)
+         ),
+         'databaseIdentity', (
+           SELECT current_database() || '/' || d.oid::text
+             FROM pg_database d WHERE d.datname = current_database()
+         ),
+         -- The cluster's own permanent name, as initdb assigned it. A second
+         -- identity rather than a replacement for the one above, because the
+         -- two answer different questions and an approval is checked against
+         -- both. This one survives the database being renamed and does not
+         -- survive the data directory being thrown away and recreated; the one
+         -- above tells two databases in one cluster apart, which is how a
+         -- staging and a production database on the same host differ. Readable
+         -- by any role that can connect: it is in the control file, not in a
+         -- catalog anybody needs rights on.
+         'clusterIdentity', (SELECT system_identifier::text FROM pg_control_system())
+       )::text;

package/src/backup/datasets.ts

@@ -8,10 +8,85 @@
 /**
  * Archive layout version. Format 2 adds accounts, email configuration,
  * verified media and secret sanitising. Format 1 archives are rejected.
+ *
+ * This is the *container* version — how the zip is arranged and what may live
+ * in it. Contract v3 changes nothing about that, which is why this number did
+ * not move and the one below it did.
  */
 export const ARCHIVE_FORMAT_VERSION = 2;
-/** Bump when the database schema changes in a way that breaks old archives. */
-export const SCHEMA_VERSION = 2;
+
+/**
+ * The database schema an archive written today describes.
+ *
+ * Bump when the database schema changes in a way that breaks old archives.
+ * Contract v3 took it to 3: pages carry a status, publications carry a
+ * signature, and the three review tables did not exist at 2.
+ */
+export const SCHEMA_VERSION = 3;
+
+/**
+ * What a reader does with each schema version it may meet.
+ *
+ * Not `version <= SCHEMA_VERSION`, and not a range. Every version answered
+ * here has a branch that says what reading it actually means, because the
+ * question is never "is this number small enough" but "does this build know
+ * what the rows in front of it describe". A comparison answers the first
+ * question while appearing to answer the second, and the day a schema 4 exists
+ * it would answer both wrongly.
+ *
+ * Both readers — the backoffice import in `server/backup-core.ts` and the
+ * standalone PostgreSQL tool in `restore-core.ts` — go through this one
+ * function, so there is no version either of them accepts alone.
+ */
+export type SchemaReading =
+  | {
+      readonly supported: true;
+      readonly version: number;
+      /** False for schema 2: it predates the review tables entirely. */
+      readonly carriesReviewHistory: boolean;
+    }
+  | { readonly supported: false; readonly version: number; readonly reason: string };
+
+export function readSchemaVersion(version: number): SchemaReading {
+  switch (version) {
+    // Written by 0.90 and 0.91. It has no review tables, no page status and no
+    // publication signature — but everything it *does* say still means what it
+    // said, and what it leaves out is recoverable by scanning the restored
+    // content. So it is read, and a reconciliation run records the scan.
+    case 2:
+      return { supported: true, version, carriesReviewHistory: false };
+
+    // Written by 0.92 and later. Carries the review history with it.
+    case 3:
+      return { supported: true, version, carriesReviewHistory: true };
+
+    default:
+      return {
+        supported: false,
+        version,
+        reason:
+          version > SCHEMA_VERSION
+            ? `it was made for a newer database (version ${version}); this site runs version ${SCHEMA_VERSION}`
+            : `version ${version} is older than any schema this build can read`,
+      };
+  }
+}
+
+/** The schema versions `readSchemaVersion` accepts. Derived, never hand-listed. */
+export const SUPPORTED_SCHEMA_VERSIONS: readonly number[] = Object.freeze(
+  [0, 1, 2, 3, 4, 5].filter((v) => readSchemaVersion(v).supported),
+);
+
+/**
+ * Prefix of every dataset name the migration approval machinery would use.
+ *
+ * Nothing emits one and nothing reads one: approval and gate records live on
+ * the VPS filesystem, root-owned and mode 0600, and are spent by the one
+ * migration they name. The constant exists so a test can state the rule
+ * positively — no archive contains a dataset under this prefix — rather than
+ * relying on nobody ever adding one.
+ */
+export const APPROVAL_NAMESPACE = "lovable_migration_approval";
 
 export {
   ALLOWED_MEDIA_EXTENSIONS,
@@ -48,6 +123,28 @@ export type TableSpec = {
    * whose parent row is absent fails analysis before anything is restored.
    */
   references?: { column: string; table: string; pk?: string }[];
+  /**
+   * Columns the database computes for itself. They are never written, on
+   * either pass — PostgreSQL refuses an INSERT that names a generated column,
+   * and it is right to: the whole point of `inputs_digest` being GENERATED is
+   * that it cannot disagree with the `inputs` it claims to cover, and an
+   * archive that could supply its own would hand that guarantee to whoever
+   * wrote the file.
+   */
+  generated?: string[];
+  /**
+   * uuid columns naming a person, paired with the column that carries the same
+   * person as text.
+   *
+   * The email is the identity that survives a restore; the uuid is a pointer
+   * into whichever accounts this database happens to have. On the way in the
+   * pointer is kept only where the account exists here, and dropped where it
+   * does not — never deferred and written back, because the tables that carry
+   * these columns are append-only and would refuse the second write. The
+   * addresses that lost their pointer are reported, so relinking is something
+   * an operator does deliberately rather than something a restore guesses.
+   */
+  actors?: { column: string; email: string }[];
 };
 
 /** Business keys used to detect that an archive comes from another database. */
@@ -95,6 +192,53 @@ export const DATASET_GROUPS: DatasetGroup[] = [
       { table: "block_templates", pk: "id" },
     ],
   },
+  {
+    id: "review",
+    label: "Publication review history",
+    description:
+      "The scans that decided what each page publishes, the pages they looked at, and the decisions people took about them. Append-only: restored history is added, never overwritten or removed.",
+    // Append-only in the database, so append-only here. The three tables have
+    // BEFORE UPDATE and BEFORE DELETE triggers that raise unconditionally, and
+    // this flag is what keeps the restore on the one path they permit: insert,
+    // and do nothing where a row already exists. A restore that could rewrite
+    // this history would be a way of laundering an unreviewed publication
+    // state through a backup file, which is the one thing the history exists
+    // to make impossible.
+    insertOnly: true,
+    tables: [
+      {
+        table: "cms_publication_review_runs",
+        pk: "id",
+        actors: [
+          { column: "classified_by", email: "classified_by_email" },
+          { column: "approved_by", email: "approved_by_email" },
+          { column: "applied_by", email: "applied_by_email" },
+        ],
+      },
+      {
+        table: "cms_publication_review_items",
+        pk: "id",
+        // (run_id, page_id) is the business key: one item per page per run.
+        // Conflicting on the uuid instead would let the same scan's view of a
+        // page arrive twice under two ids.
+        conflict: "run_id,page_id",
+        requires: ["pages", "cms_publication_review_runs"],
+        generated: ["inputs_digest"],
+      },
+      {
+        table: "cms_publication_review_decisions",
+        pk: "id",
+        // An item is resolved at most once and for good, so item_id is the
+        // conflict target: an archived decision either inserts, because the
+        // item had none, or is refused. There is no upsert that supersedes a
+        // local decision, and `reviewConflicts` reports the collision rather
+        // than letting DO NOTHING swallow it.
+        conflict: "item_id",
+        requires: ["cms_publication_review_items"],
+        actors: [{ column: "resolved_by", email: "resolved_by_email" }],
+      },
+    ],
+  },
   {
     id: "seo",
     label: "SEO & routing",
@@ -209,6 +353,9 @@ export const IMPORT_ORDER: string[] = [
   "pages",
   "page_versions",
   "page_publications",
+  "cms_publication_review_runs",
+  "cms_publication_review_items",
+  "cms_publication_review_decisions",
   "global_sections",
   "global_section_versions",
   "content_sections",
@@ -232,6 +379,60 @@ export const IMPORT_ORDER: string[] = [
   "email_logs",
 ];
 
+/**
+ * The order Replace mode empties tables in: the exact reverse of IMPORT_ORDER.
+ *
+ * Written out rather than computed, and a test asserts the two are reverses of
+ * each other. `IMPORT_ORDER.slice().reverse()` would always be the reverse of
+ * whatever IMPORT_ORDER happened to say, including after somebody moved a
+ * table into the wrong place — it agrees by construction and so proves
+ * nothing. Two lists that must mirror each other disagree loudly the moment
+ * one of them is edited alone, which is the only version of this that is worth
+ * having.
+ *
+ * Order is not a preference here. `cms_publication_review_items.page_id` and
+ * `.run_id` are ON DELETE RESTRICT, so clearing pages before items raises
+ * instead of quietly cascading the review history away. That refusal is the
+ * intended behaviour: it turns an ordering mistake into a failure somebody
+ * reads, rather than into evidence nobody notices is gone.
+ *
+ * Insert-only tables are in the list and are never cleared — `buildClearPlan`
+ * leaves them out of every plan it builds. They are listed here because the
+ * list is a statement about the dependency graph, and a graph with holes in it
+ * cannot be checked.
+ */
+export const CLEAR_ORDER: string[] = [
+  "email_logs",
+  "audit_logs",
+  "media_trash",
+  "media_focus",
+  "media_meta",
+  "form_delivery_attempts",
+  "form_partials",
+  "form_submissions",
+  "form_settings",
+  "form_versions",
+  "forms",
+  "email_settings",
+  "email_providers",
+  "site_injections",
+  "locale_domains",
+  "redirects",
+  "page_seo",
+  "block_templates",
+  "content_sections",
+  "global_section_versions",
+  "global_sections",
+  "cms_publication_review_decisions",
+  "cms_publication_review_items",
+  "cms_publication_review_runs",
+  "page_publications",
+  "page_versions",
+  "pages",
+  "user_roles",
+  "app_users",
+];
+
 export type ArchiveManifest = {
   format: number;
   schemaVersion: number;