Yuvomi

Fixed

• WebDAV backup rotation deleted the newest backup instead of the oldest (#853). On a Synology - and on anything else running Apache mod_dav - the file listing was read back without a single timestamp, and the rotation then removed from the wrong end. Every scheduled run uploaded a fresh backup and deleted it seconds later, while the seven oldest stayed. A household could keep the feature switched on for months and never hold a recent remote backup.

  The namespace prefix in a WebDAV answer is the server’s to choose. Nextcloud writes <d:getlastmodified>; mod_dav publishes live properties under a prefix of its own, as <lp1:getlastmodified>. The parser insisted on D: or d:, found no date, and substituted “now” for every file - which did not fail, it tied. A tie sorts to nothing, so what was left was the server’s own order: by name, oldest first. slice(keep) then cut the newest end off.

  Three things changed, and the first one is the fix: the prefix is now read as whatever the server sent, including none. Second, a missing timestamp stays missing instead of becoming “now” - an invented date is worse than an absent one, because it quietly turns a sort into an equality. Third, ordering leans on the timestamp Yuvomi itself wrote into the filename, which no server quirk can touch, and falls back to getlastmodified only for files it did not name.

  On top of that the rotation will no longer delete the file it just uploaded, whatever the sort says. Should a server ever confuse the ordering again, that now costs one surplus old backup rather than the only fresh one.

  Also fixed along the way: a server answering with absolute hrefs (which RFC 4918 allows) had its paths pasted onto the base URL, so those DELETEs went nowhere and the folder grew without bound.

• Editing an event repainted it in a colour nobody picked (#856). Open an event, change the assignee or just the title, save - and the event came back in the palette’s first blue. Nothing had touched the colour. It happened to every event whose colour was not literally one of the ten swatch values: an assignee’s avatar colour, an RFC 7986 COLOR from a CalDAV server, or the #007AFF that events carried before the OKLCH palette arrived.

  The colour picker matched the stored colour against its ten swatches to decide which one to mark active. The two palettes involved share no value at all - avatar colours are the old iOS system set (#007AFF, #34C759, …), event colours the OKLCH set (#587DCE, #3CA368, …) - so for those events no swatch lit up. The picker looked as though no colour was set. Saving then read the active swatch, found none, and fell back to EVENT_COLORS[0].

  Two things changed. The picker now shows the colour the event actually has, as an extra swatch in front of the palette, so it stops claiming nothing is set. And saving follows one rule: a save that did not touch the colour does not change it - without an active swatch the event keeps the colour it already had, and only a genuinely new event falls back to the palette.

  Swatch matching is also no longer case-sensitive. #587dce and #587DCE are the same colour, and CalDAV servers routinely send the lower-case form.

Changed

• The colour picker no longer greys itself out when someone is assigned. It used to, with the note “colour is overridden by the assigned person(s)” - and that had been untrue since 2.35.0. Since #815 the event’s own colour comes first in the priority order, and because calendar_events.color is NOT NULL and rejects an empty string too, an event always has one. The assignee’s colour has not tinted anything since; the note promised what the code had stopped doing, and the greyed-out picker took a choice away to keep that promise. Both are gone. Who an event belongs to is still shown, by the avatar stack beside it.