Split automated emails into pair for future extensibility

[EvanHahn]

closes https://linear.app/ghost/issue/NY-1188

I recommend reviewing this commit-by-commit.

We currently have one table for welcome emails: automated_emails. Instead, we want a table for automations and a table for all the emails in that automation.

This change isn't useful on its own, but will be followed up with the ability to add more than one email to an automation.

This change should have no user impact.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 24eb6de2-b688-4e50-b429-51b6992f12f9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch NY-1188

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

It looks like this PR contains a migration 👀
Here's the checklist for reviewing migrations:

General requirements

• ⚠️ Tested performance on staging database servers, as performance on local machines is not comparable to a production environment
• Satisfies idempotency requirement (both up() and down())
• Does not reference models
• Filename is in the correct format (and correctly ordered)
• Targets the next minor version
• All code paths have appropriate log messages
• Uses the correct utils
• Contains a minimal changeset
• Does not mix DDL/DML operations
• Tested in MySQL and SQLite

Schema changes

• Both schema change and related migration have been implemented
• For index changes: has been performance tested for large tables
• For new tables/columns: fields use the appropriate predefined field lengths
• For new tables/columns: field names follow the appropriate conventions
• Does not drop a non-alpha table outside of a major version

Data changes

• Mass updates/inserts are batched appropriately
• Does not loop over large tables/datasets
• Defends against missing or invalid data
• For settings updates: follows the appropriate guidelines

[github-actions]

E2E Tests Failed

To view the Playwright test report locally, run:

REPORT_DIR=$(mktemp -d) && gh run download 23914992609 -n playwright-report -D "$REPORT_DIR" && npx playwright show-report "$REPORT_DIR"

[sonarqubecloud]

Quality Gate failed

Failed conditions
9.6% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[cmraible]

Throwing a bit of a wrench in your plans, sorry! The changes themselves all make sense (though I haven't looked too closely beyond the first commit), but I think we should split up this one migration into a couple more focused migrations — see comment below.

[cmraible]

I would probably split this migration into a couple of separate migrations. The main smell for me is that this mixes DDL and DML in a single migration. I wouldn't say this is a hard rule (a few existing migrations do violate this), but unless we have a good reason to mix the two, I think it's worth splitting them up. Beyond just being a bit easier to reason about, MySQL has some quirks where e.g. DML operations like creating tables are committed immediately (regardless of any transactions). The risk there is that parts of the migration could succeed, while others fail, leaving the DB in a partially migrated state.

As written today (though I think some of this will change with the data model changes you mentioned), I'd split this into probably 3 migrations:

1. Create both tables
2. Backfill from automated_emails, along with any code changes needed for welcome emails to continue to function with these new tables
3. Add/update foreign keys and drop automated_emails