Support for multiple separate calendars instead of merging into 1

[torbenvanassche]

I noticed while migrating from FamilyWall to Yuvomi that the calendar gets merged into one. It's likely better to be able to add multiple calendars for different purposes. e.g. I don't need to see Birthdays on my freelance schedule.

[ulsklyc]

Thanks, this is a fair observation about how import works.

What you ran into is the one-time import (Settings > Personal > Calendar subscriptions > Import calendar). It turns the file into your own, editable events with one colour per import, and afterwards they no longer know which calendar they came from. That is why everything ends up together.

What already keeps calendars apart:

• Connected Google, Apple and CalDAV calendars and ICS subscriptions each keep their own name and colour. Since 2.66.0 the calendar filter has a switch for each of them, remembered per device (Calendar: filter by calendar and subscription, and an axis for events nobody is assigned to #1064).
• Birthdays are a separate layer with their own switch in the same filter.
• ICS subscriptions can be private or visible to everyone.

What does not exist yet is a calendar of Yuvomi's own: events created or imported in Yuvomi belong to no calendar, so they cannot be hidden as a group. If your FamilyWall calendars can be subscribed to through separate ICS links, adding each one as a subscription keeps them apart, read-only.

Separate local calendars would be a new part of the data model, close to the personal calendar connections discussed in #739, so I'm leaving this open to think it through.

[torbenvanassche]

It seems strange that imported calendars get merged, but I can also see the reason why that would happen. The reason I found this out, is because I linked the ICS to my home assistant and noticed that everything was in one calendar, rather than the familywall way I had separate ICS entries for each calendar type (private, work, birthdays etc)

Similar to the other topics I've raised today, I also have a feature branch for this on a local fork I am running on my own server. If it is being discussed, I would be able to set up a PR for this as well, you can review if you want, or I can run it on my server for a bit to see and check if it works properly.

The tests are succeeding though as far I can see :)

[ulsklyc]

Thanks, that use case helps: what you need in Home Assistant is one ICS feed per calendar, not only separate views inside Yuvomi. Feel free to open your branch as a draft PR, so we can look at a concrete model. To be upfront: it won't be merged until the model is settled, because a calendar of Yuvomi's own changes how events are stored, imported, exported and synced, and it sits right next to the personal calendar connections discussed in #739. In the draft I'll mainly look at:

• where the calendar lives in the schema, and what existing events get when the migration runs
• what the one-time import writes into
• how the ICS feeds are split per calendar, and who can subscribe to which
• how it relates to connected Google, Apple and CalDAV calendars, the calendar filter and the person filter

A short description of that model in the PR text would help most. If it needs migrations, take a number after the current queue (#1181 holds 210-213).

[torbenvanassche]

To be upfront: it won't be merged until the model is settled, because a calendar of Yuvomi's own changes how events are stored, imported, exported and synced, and it sits right next to the personal calendar connections discussed in #739.

Very much understandable, the changes I'm asking for are quite low-level in relation to the calendar implementation and I would hate to go against the architecture or add code not in line with repo rules. I respect the strict contribution guidelines 😄

* what the one-time import writes into

Implementation for the one-time import is allowing users to define where to import to (or create a new one during the import).

* how the ICS feeds are split per calendar, and who can subscribe to which

Ownership for ICS would be an administrator, potentially an owner of the calendar (assuming there is one, comparing it to the budget component) or whoever has access to the calendar as a user so they can subscribe, seems mostly up to preference.

* how it relates to connected Google, Apple and CalDAV calendars, the calendar filter and the person filter

Not sure there is a relation, a local calendar adds local events only. if events are also coming from CalDAV or some online calendar I don't see that being a problem for writing to the calendar (excluding a de-sync between what the user sees on that calendar and on the linked online calendar, but frankly that would be their own fault. Combining the 2 could also be disabled if desired)

A short description of that model in the PR text would help most. If it needs migrations, take a number after the current queue (#1181 holds 210-213)

Noted.

[torbenvanassche]

The draft PR is in #1243. Added to the queue at 217

[ulsklyc]

Thanks, I have it. Everything further belongs in #1243 rather than here, so I will keep this thread as the place where the model question lives and comment on the branch itself. One thing to fix before I read it: main has since taken migration 217 for itself, so your number collides - move yours up to the next free one.