The current implementation of group sharing has some shortcomings:
- The
/caldav-compat endpoint causes pain on Apple devices and tasks.org as some clients don't accept reliably accept the explicit configuration of a principal url.
- Sharees directly access the shared calendar meaning the cannot adjust the displayname and colour for themselves but most importantly, deletion is global.
Requirements for a proper implementation:
- We want to store shares in a dedicated table to allow sharees to customise metadata but also to allow them to reject a share without deleting it globally.
- Allow users to share individual calendars without this membership-based mechanism
- The
/caldav-compat endpoint must be able to serve all shared calendars
Nice to haves:
- Access control: read-only shares
Initial idea
addressbooks
calendars
principals
birthday_calendars: Refers to addressbooks
We'd introduce two new tables:
addressbook_shares: Refers to principals, addressbooks
calendar_shares: Refers to principals
One problem is birthday_calendars.
- Either we enable sharing of birthday calendars, then the foreign key of
calendar_shares can point to either calendars or birthday_calendars
- Or we enable creating birthday calendars on shared addressbooks, then
birthday_calendars would need to refer to either addressbooks or addressbook_shares.
Foreign keys on two tables are not really feasible. :(
addressbook_views/calendar_views tables
Alternatively, introduce addressbook_views/calendar_views tables.
The addressbooks/calendars tables would only contain internal information such as sync token, push topic, and act as a reference for objects.
The corresponding view tables would then contain the target principal, access control information, as well as metadata, such as displayname, description, and colour...
The view table could also contain a principal-specific id such that we don't have to manage weird _shared_$user$calid prefixes.
This approach will finally make the multi-home approach redundant, allowing us to get rid of the /caldav-compat endpoint. :)
The current implementation of group sharing has some shortcomings:
/caldav-compatendpoint causes pain on Apple devices and tasks.org as some clients don't accept reliably accept the explicit configuration of a principal url.Requirements for a proper implementation:
/caldav-compatendpoint must be able to serve all shared calendarsNice to haves:
Initial idea
addressbookscalendarsprincipalsbirthday_calendars: Refers toaddressbooksWe'd introduce two new tables:
addressbook_shares: Refers toprincipals,addressbookscalendar_shares: Refers toprincipalsOne problem is
birthday_calendars.calendar_sharescan point to eithercalendarsorbirthday_calendarsbirthday_calendarswould need to refer to eitheraddressbooksoraddressbook_shares.Foreign keys on two tables are not really feasible. :(
addressbook_views/calendar_viewstablesAlternatively, introduce
addressbook_views/calendar_viewstables.The
addressbooks/calendarstables would only contain internal information such as sync token, push topic, and act as a reference for objects.The corresponding
viewtables would then contain the target principal, access control information, as well as metadata, such as displayname, description, and colour...The
viewtable could also contain a principal-specificidsuch that we don't have to manage weird_shared_$user$calidprefixes.This approach will finally make the multi-home approach redundant, allowing us to get rid of the
/caldav-compatendpoint. :)