Send invitations for shared calendars

[kesselb]

Ref: #15676

It's not possible (anymore) to send invitations for an event for shared calendars. This behavior is confusing for end users.

Allowing sharees to send invitation in shared calendars was a mistake back then, there are many unresolved topics, especially if the sharee is also an attendee of the event:

• when editing, does the sharee edit for themselves or on behalf of the calendar owner?
• when deleting, is the sharee declining the event for themselves or cancelling it for everyone?
• ...

The CalDAV standard does not have answers to these problems yet. Until then, we should not allow sharees to send invitations in shared calendars.

https://sabre.io/dav/caldav-sharing/ mentions

• https://tools.ietf.org/html/draft-pot-webdav-resource-sharing-04
• https://tools.ietf.org/html/draft-pot-caldav-sharing-00

Unfortunately there is no final RFC how shared calendars should work. Yet the drafts could be a starting point. draft-pot-caldav-sharing-00 describes those open issues:

1. DAV:owner requirement for scheduling. I think this is
   problematic...

2. I don't think we should allow sharees that have access to an
   invite for which they are the attendee for, via the organizers
   shared calendar, to allow them to make attendee-related changes.
   The entire collection should operate as if the operation is on
   behalf of the organizer.

We don't implement https://github.com/sabre-io/dav/blob/master/lib/CalDAV/Backend/SharingSupport.php interface yet. That might be something to start with. There is already some logic connected to the above interface in sabre that might be useful.

The example implementation https://github.com/sabre-io/dav/blob/c1afdc77a95efea6ee40c03c45f57c3c0c80ec22/lib/CalDAV/Backend/PDO.php#L1308-L1465 uses a database table calendarinstances that looks similar to oc_calendars and oc_dav_shares. For example calendarcolor is something we store with the calendar. But for a shared calendar the color is something a user may change. So this needs to go to oc_dav_shares (calendarinstance in the sabre example).

[ChristophWurst]

Some related sharing limitations are discussed at #5050.

[favincen]

We don't implement https://github.com/sabre-io/dav/blob/master/lib/CalDAV/Backend/SharingSupport.php interface yet. That might be something to start with.

👍 ! Seems pretty close to the suggestion I made in #15676 (comment), regarding the issue that currently used "getUsersOwnCalendars" does not list calendars shared to the user, and that some kind of "getUserEditableCalendars" method would be of great help. 😇

[rasos]

Workaround: Create a team meeting in your personal calendar, check sending e-mail notifications, and then change the assignment of the event to your team calendar. Drawback: if you change the date, nobody is notified again, unless you assign the event back to a calendar you own, do the shift and assign it back to the team calendar.

As this is a bit hard to explain and understand we think that an extra method "getUserEditableCalendars" that controls the Send email checkbox would be the experience that users expect. Now you see this checkbox even if you don't have the rights to send an e-mail (and you wonder why nobody confirms the event).

We always recommend that teams should create an extra user who then owns the team's root folder, addressbook and also calendar. Those should not belong to a person, as the team would loose those assets if a founder leaves the team.

[ChristophWurst]

We have found the Sabre invitation plugin to skip invites if the organizer of the event is not the owner of the calendar. Right now that happens for shared calendars because \OCA\DAV\CalDAV\Calendar::getOwner overwrites \Sabre\CalDAV\Calendar::getOwner. Upstream returns the principaluri of the owner, we return the principaluri of the sharee.
We want to test if this revives the invites in shared calendars. We might need some adjustments for other places that use the getOwner method.

The method overwrite was added in owncloud/core#21964, before Sabre supported sharing

[subroutineox]

i really wish you guys all the best in fixing this issue - it is really the main problem for us to fully commit to nextcloud Hub. thanks for your hard work!

[SebastianKrupinski]

@subroutineox are you interested in testing the fix? and giving us feed back?

Here is the fix.

#45054

[subroutineox]

@subroutineox are you interested in testing the fix? and giving us feed back?

Here is the fix.

#45054

Thank you for the offer. Sadly i dont have a testing environment and might not have the knowledge that might be needed to properly help. Best wishes

[bpmartin20]

I'd be very pleased to help test the fix, however I'm not wild about moving my whole stable 29.0.4 installation to a development version. Is there a way I can install just this patch, or is it likely to have dependencies that aren't present in stable?

[outofcontrol]

We might be able to test. Need a couple of days to ensure I have the allowance from my client that is most affected by this, to snaphot/upgrade/test their install. Will know more in a couple of days.

[SebastianKrupinski]

@outofcontrol just an FYI, the fix is two parts. One part is to fix the issue with shared calendars in the server code, that part is a straight copy and paste of the affected file. The second part is to enable the option in the calendar, this would need to be compiled with npm first (npm ci && npm run build) as it modifies the some of the java script in the UI.

[bpmartin20]

So in the repository I see two branches for 26668:

• origin/feat/26668/notifications-for-shared-calendars-2
• origin/fix/issue-26668
  They appear to conflict, as they have updates for some of the same files. Which should I be testing?

[SebastianKrupinski]

@bpmartin20 you should test this one. #45054

Please read the instructions there is also a patch for the calendar app that needs to be pulled