Fixed
- A synced series keeps its recurrence when you edit the appointment. An appointment read in over CalDAV stores its rule as the full calendar line, with the
RRULE:prefix that belongs to it. The form read the rule without that prefix in mind, so the very first segment came out asRRULE:FREQand nothing matched: a weekly series arrived in the editor as "no repetition", and saving wrote that emptiness down. The sync then carried the loss back into the calendar it came from, which for the reporter meant the appointment stopped recurring everywhere. The rule is read in both spellings now. Beyond that, a rule goes back exactly as it came whenever nobody touched the repetition fields - this form knows five parts of RFC 5545, and a rule carryingBYSETPOSorWKSTwould otherwise have been simplified into something else while the user was only changing the assignee: "every third Thursday" quietly becoming "every month". Changing or clearing the repetition still does what it says. The server accepts an unchanged rule without running it past its validator, because it is already in the database - without that, every edit to any other field would have failed on a repetition the user never looked at. In the same pass, a locally created series pushed to an Apple calendar gets a validRRULE:line again instead of a property without a name. - A recipe with no meal ticked stays that way. Clearing all four boxes and saving turned into all four being set, silently: the form only revealed it when you opened the recipe again and found every box ticked. What made that expensive is the meal plan's random pick, which draws from whatever a recipe declares - a stock or a base sauce could not be kept out of it. An empty selection now means what it says: the recipe is in no meal filter and in no random pick, and it says so with a "no meal" badge rather than showing nothing. It stays fully usable by hand - the plan dialog offers all four meals for it, and it can still be dragged into any slot, because dragging it there is the decision. An absent field still means all four, so nothing changes for a client that never sends one, and a partial update no longer drags the selection along with it. For third-party modules on
/api/v1/recipesthis is a behaviour change worth noting:meal_types: []used to come back as all four and now comes back empty. - "Refresh calendars" no longer switches every calendar back on. Fetching the list from a CalDAV account deleted the stored selection and wrote it back with everything enabled, so a calendar deliberately unticked came back into the sync unasked - along with its appointments on the next run. The list is refreshed, the selection is kept: a calendar the server newly reports still defaults to on, a known one keeps whatever it was. The same reset sat a second time in the credentials path, where changing a password had the same effect.
- The default assignee can be set before the sync runs, not after. It was available exactly as long as it had no effect: the picker appeared only once a calendar had been synced, by which time the first and usually largest batch of appointments was already in, unassigned and to be corrected by hand - for recurring appointments many times over. The picker now stands on every calendar of a connected account, including before you tick it, and the ICS subscription form asks for the assignee while creating rather than only in the edit dialog it opens afterwards.
- "Cancel" works in the edit view of an item. Opening a task, tapping "Bearbeiten" and then "Abbrechen" did nothing at all. The cancel buttons were wired once when the dialog opened, and the edit form is deliberately built later, only on the tap - so its button never got a handler. It is delegated now, which repairs the same dead button in every module with a read view: tasks, shopping, pantry, housekeeping and recipes.