Skip to content

Proper sharing that just works #176

@lennart-k

Description

@lennart-k

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. :)

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions