Recipes: let owners activate a version at will (today activation requires logging a cook)
Maintainers usually reply within 1 day
A pull request for this has already been merged.
- #462 by @spudly — merged
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start with the existing versioning tests referenced in #77 and trace how cook logging changes a recipe’s active version. Then find where the recipe version UI and the recipe page, meal plans, shopping lists, and get_recipe resolve the active version. Done when an owner can deliberately activate a saved version, those reads use it, prior versions remain available, non-owners receive a clear error, and the behavior is covered by tests.
Written by the indexing model from the issue text.
Description
Problem
A recipe version cannot be made the active version directly. Today the only way a new version becomes active is as a side effect of logging a cook against it — there is no "activate this version" action anywhere in the app.
Concrete case (2026-11-03): Fiesta Lime Chicken Tacos was split into two recipes (the tacos, plus a standalone Pineapple Salsa). The cleaned-up tacos content was saved as v2 (salsa ingredients/steps removed) and marked Perfected — but the recipe still serves v1 as Active, salsa and all. Both the recipe page and the v2 edit page were checked: the version selector labels v2 "Draft" and v1 "Active", and no publish / make-active control exists. Verified via the API as well: get_recipe still returns v1's content.
Logging a cook just to flip which version is active is wrong for edits that have nothing to do with a cook session — recipe maintenance (splitting a recipe, fixing an ingredient, correcting steps) shouldn't require pretending to cook the dish.
Proposed change
Add an explicit Activate version action for recipe versions:
- Available from the recipe's version UI (version selector / version history) for any saved version the owner could reasonably promote — at minimum, Perfected versions; whether Draft versions can be activated directly or must be Perfected first is an open design question for the fix.
- Activating a version makes it the version the recipe page, meal plans, shopping lists, and API/MCP reads serve — immediately, with no cook log required.
- Owner-only, like other recipe edits.
- Keep the existing cook-log activation behavior working as it does today; this adds the missing direct path, it doesn't replace the cook flow.
- Reasonable safeguards are fine (e.g. a confirm step, since meal plans resolve through the active version), but activation must be a deliberate user action on the version itself — not a side effect of an unrelated workflow.
Acceptance criteria
- On Fiesta Lime Chicken Tacos: open v2, activate it, and the recipe page +
get_recipeserve v2's content — without logging a cook. - The previously active version remains in history, unchanged and re-activatable.
- Meal plans referencing the recipe resolve against the newly active version after activation.
- Only the recipe owner can activate a version; attempts on another user's recipe error clearly.
- Covered by tests consistent with the existing versioning tests (#77).
Related: #77 (versioning workflow), #410 (the MCP-side counterpart — editing content through MCP; even with that, app users need this direct activation path).
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 8h 48m
- Merged PRs (30d)
- 209
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from spudly/eciperay
-
blocked needs_human priority-p2
Difficulty 2/5 Half a day Newbie friendliness 68/100
spudly/eciperay#31 · 1 comment ·
Maintainers usually reply within 1 day
-
Android release build fails applying expo-autolinking plugin (expo-constants libraryVariants) — regression from #464Possibly taken @spudly claimed this today. Openblocker bug priority-p1 scale-md
Difficulty 4/5 3-5 days Newbie friendliness 25/100
spudly/eciperay#466 · 2 comments ·
Maintainers usually reply within 1 day
-
enhancement priority-p2
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
bug priority-p2
Difficulty 3/5 1-2 days Newbie friendliness 66/100
spudly/eciperay#461 · 3 comments ·
Maintainers usually reply within 1 day
-
enhancement priority-p2
Difficulty 5/5 Over a week Newbie friendliness 35/100
spudly/eciperay#460 · 4 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
backnotprop/plannotator#2914 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
microsoft/vscode-containers#655 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dsh-tauri-desk/deepseek-harness-desktop#1477 · 1 comment ·