Open the linked recipe from a planned-meal card

[MrWoodsOWS]

When a meal in the weekly planner is linked to a recipe stored in Yuvomi, clicking the meal card opens the meal editor rather than the recipe.

The small external-link action only appears when a meal has a recipe_url, so there is no quick way to view the actual recipe while cooking from the plan.

Could the meal-card click open the linked internal recipe when recipe_id is present, with editing available via a separate action (or vice versa with a visible “View recipe” action)? It would make the meal plan much more useful as the route into cooking.

[ulsklyc]

Umgesetzt in #943.

Deine Diagnose stimmt genau: Das Feld gibt es, es wird gespeichert, die Einkaufslisten-Übertragung wertet es aus - nur der Weg zurück zum Rezept fehlte. Der Aktionsknopf war an recipe_url gebunden, also an die externe Adresse, und ein Rezept aus dem eigenen Haus hatte keinen Ausgang. Man konnte die Verknüpfung anlegen und nie benutzen.

Von deinen zwei Vorschlägen habe ich den zweiten genommen - sichtbare Aktion statt geändertes Klickverhalten. Der Klick auf die Karte ist für alles andere weiter richtig, und ein umdefinierter Haupt-Klick träfe auch jeden, der das Essen nur umbenennen will. Der Knopf steht neben den bestehenden und trägt eine Kochmütze.

Er führt auf /recipes?open=<id>, wo das Rezept aufgeklappt und ins Bild gescrollt wird. Die Schreibweise ist nicht neu: Kontakte und Startseite benutzen ?open= bereits, /recipes liest sie jetzt auch.

Aufgeklappt statt geöffnet zum Bearbeiten - wer aus dem Essensplan kommt, will kochen. Dieselbe Entscheidung, die die Rezeptliste beim Antippen einer Zeile schon trifft.

Hat ein Essen beides - internes Rezept und externe URL -, gewinnt das interne. Der Sprung dorthin bleibt in der App.

Ich lasse das hier offen, bis die PR durch ist.

[ulsklyc]

Released in v2.55.0.

A meal card with a linked recipe now carries a second button that opens it - expanded and ready to read rather than open for editing, since whoever comes from the meal plan wants to cook. It goes to /recipes?open=<id>, the same deep-link spelling Contacts and the Overview already use.

Three things came out of review that are worth mentioning, because two of them were real bugs in the first version:

• On phones the button moved the meal instead of opening the recipe. The drag guard exempted three actions by name, and the new one was not among them, so its press started a drag and releasing over another slot rescheduled your meal. The guard now names the action bar as a whole rather than its occupants.
• With the Recipes module switched off the button pointed at a page that redirects to the dashboard - and because it took precedence, a meal with both a recipe and a web address lost the working external link too. It is now conditional on the module being reachable.
• A leftover filter could hide the target. If you had last searched the recipe list, coming back through the link rendered a filtered list the recipe might not be in, and the jump ended silently in nothing. A named target beats an old filter, so the filter is cleared.

A meal that has both a recipe and an external address shows the recipe, since that jump stays inside the app.