Clarifying the readability issue in the calendar after the recent event‑color update

[Imanity-jhn]

The recent update to the calendar forces every event to use a fixed color, which prevents the event from inheriting the color of the associated family member. Even though the person’s icon still appears, the event no longer visually matches its owner, creating a visual inconsistency that makes the calendar harder to read at a glance. This breaks the immediate color‑based recognition that helps users quickly understand who an event belongs to. To restore clear readability, the calendar should support both behaviors: allowing events to automatically use the person’s color, or letting users manually choose a specific event color when needed. Supporting both options would maintain visual coherence while preserving the flexibility introduced in the update.

Kind regards,

[ulsklyc]

Thanks - and you are right that something changed. Let me lay out exactly what, because the current behaviour is not a lost feature but a structural dead end that I want to be honest about.

What changed and why. Until v2.35.0 the display order was assignee colour before the event's own colour. That was reported in #815 by someone whose CalDAV events carried real per-event colours, set in Baikal and Nextcloud - they arrived in Yuvomi correctly, and then the assignee colour painted over every one of them. The rule threw away an explicitly set value in favour of a derived one. Since v2.36.0 the event's own colour wins, which is why yours now looks fixed rather than inherited.

Why "both behaviours" is not a setting today. calendar_events.color is NOT NULL and rejects the empty string as well. There is no state that means this event has no colour of its own - every event always has one, so the assignee colour and the calendar colour are effectively dead code in the resolver. A toggle would have nothing to fall back to.

Making it real needs three things, in this order:

1. a migration to a nullable colour, so "not set" becomes expressible
2. a backend that accepts the deletion - COALESCE in the write path currently swallows it
3. only then a choice, and the honest default is assignee colour when the event has none of its own, not a global switch

Where I land. I think you and #815 both want the same thing and the disagreement is only about the default. An explicit value should beat a derived one - that part I would not reverse. But an event that never had a colour chosen for it has no business overriding the person's, and today it does, silently. That is the actual bug in the current state, and it is worth fixing.

One thing that would help me size the default: are your events getting their colour from a synced calendar, or are they created in Yuvomi and just picking up the palette's first entry? #856 fixed a case where editing an event silently rewrote its colour to the first swatch - if you are on a version before v2.37.0, some of what you are seeing may be that rather than the precedence rule.

Related: #815, #856.

[ulsklyc]

Built, and it went the way I described - with one correction to my own comment above.

The fix is #896. What I got wrong up there: I called the default question the open one and the precedence rule settled. It is the other way round. An event that never had a colour chosen for it was carrying one anyway, and that was the whole bug - the rule from #815 was never the problem, because it only ever said "an explicit value beats a derived one" and there was simply no such thing as "no explicit value".

What shipped:

1. The column is nullable (migration 166), so "this event has no colour of its own" is finally a state.
2. All four sync services stop writing the calendar's colour into it. That was the quiet half: an inherited colour, once stored per event, is indistinguishable from a chosen one. It now reaches the display as cal_color - and for ICS subscriptions, which have no external_calendars row, from ics_subscriptions, so a subscribed feed keeps its colour.
3. The dialog gets a first swatch, "colour of the assigned person", and a new event starts there. Pick a colour and it stays, for the event and across syncs.

So both behaviours exist, but not as a global switch - which I think is the better answer to what you and #815 both asked for. The switch would have needed a household to agree on one rule for every event; per event, nobody has to.

Existing events are left alone, deliberately. #007AFF looks like an old default and no current palette contains it - but it was the first entry of the event palette before the OKLCH switch, so an event from the v1 era may carry it on purpose. A migration cannot tell the two apart, and throwing away a real choice is worse than changing nothing. Your synced events normalise themselves on the next sync; anything created in Yuvomi takes one visit to the dialog.

Which brings me back to my question, still worth an answer for a different reason: if your events are synced, they will correct themselves and you need do nothing. If they were created in Yuvomi, they carry a stored colour that I am not going to overwrite for you - you would set them to the new first swatch yourself. And if you are on a version before v2.37.0, part of what you are seeing is #856 rather than this, and updating fixes that half on its own.

Leaving this open until the release. Thanks for the report - the thread is what turned "the picker looks odd" into a structural fix.

[ulsklyc]

Released in v2.49.0.

An appointment nobody picked a colour for now takes the colour of the person it belongs to, and the event dialog opens on a new first swatch - "colour of the assigned person" - which is where a new appointment starts. Choosing a colour still keeps it, in the calendar and across syncs.

As written above, your existing appointments are deliberately left alone: a stored #007AFF cannot be told apart from one somebody chose on purpose, since it was the palette's first entry before the OKLCH switch. Synced appointments normalise themselves on the next sync; anything created in Yuvomi takes one visit to the dialog.

Three things turned up while building it that are worth naming, because they were all the same shape - the same question answered in more than one place:

• The overview resolved event colours on its own, without the assignee branch. It reads the shared rule now, as does the countdown tile, which would otherwise have shown a generic tone next to a calendar showing the person's colour.
• Clearing a colour on a Google-mirrored appointment now clears it there too. A PATCH only touches the fields present in the request, so omitting the colour meant "leave it alone" - the two sides would have stayed different forever.
• The colour follows the primary assignee, and a request that does not mention the assignment no longer re-picks one. Splitting a recurring series sends exactly such a request, and it could have repainted the earlier occurrences.

Leaving this open for you rather than closing it: if the appointments you were looking at were created in Yuvomi, they still carry their stored colour and will not change on their own. Say so if that is the case and it still reads wrong after the update - and if they came from a synced calendar, one sync should be enough.

Thanks for the report. The thread turned "the picker looks odd" into a structural fix, which is the more useful kind.