Added ability to turn the automation on and off

[EvanHahn]

ref NY-1281
closes NY-1267

Screencast.mp4

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Adds useEditAutomation mutation hook that PUTs status updates to /automations/:id/, invalidates and updates cached automations, refactors AutomationHeader to accept externally-provided loading and action props, wires editor local editState with confirmation and retry flows around the mutation, adds an AutomationEditState type, extends unit tests to cover publish/unpublish interactions, and updates the Ember↔React state bridge mapping to ignore AutomationsResponseType events.

Possibly related PRs

• TryGhost/Ghost#27853: Implements the backend edit endpoint and service used by the PUT /automations/${id}/ call.
• TryGhost/Ghost#27851: Introduces the AutomationStatus type referenced by the new useEditAutomation payload.
• TryGhost/Ghost#27852: Prior changes to automation-header.tsx that this PR further modifies and consumes.

Suggested labels

ok to merge for me

Suggested reviewers

• troyciesco

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding the ability to turn automations on and off, which matches the core functionality across all modified files.
Description check	✅ Passed	The description references relevant Linear issues (NY-1281, NY-1267) and includes a visual demonstration asset, providing context related to the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

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

---

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.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/admin-x-framework/src/api/automations.ts`:
- Around line 76-80: The request body is using the wrong envelope—body:
({status}) => ({ automations: [{ status }] })—but the API expects a single
automation object; update the body function in
apps/admin-x-framework/src/api/automations.ts to return automation: { status }
instead of automations: [{ status }] so publish/unpublish uses the correct
contract (locate the arrow function labeled body that destructures status and
replace the array envelope with the single automation object).

In `@apps/posts/src/views/Automations/editor.tsx`:
- Line 27: The pending mutation state currently uses editMutation.isLoading for
any in-flight edit which can affect the wrong automation after a route change;
update the logic that computes pendingStatus so it only considers the mutation
if editMutation.variables?.id matches the current automation's id (e.g.,
automation.id or currentAutomationId) — i.e., scope the isLoading check to
editMutation.variables?.id === automation.id before returning
editMutation.variables?.status (otherwise return undefined). This change touches
the pendingStatus computation that references editMutation and the current
automation id in editor.tsx.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f0fb70f3-e21f-4f97-b078-3c053ab0ea70

📥 Commits

Reviewing files that changed from the base of the PR and between fe9dfb3 and 184dd74.

📒 Files selected for processing (5)

• apps/admin-x-framework/src/api/automations.ts
• apps/posts/src/views/Automations/components/automation-header.tsx
• apps/posts/src/views/Automations/editor.tsx
• apps/posts/test/unit/views/automations/automation-editor.test.tsx
• ghost/admin/app/services/state-bridge.js