apps/dav: add some OSX specific quirks.

[rotdrop]

• Resolves: macOS calendar: Can't search for delegates to add #17053

Summary

Following @georgehrke suggestion in the linked issue this PR adds a special QuirksPlugin which tweaks report requests from the half-eaten-apple OS to include the apply-to-principal-collection-set flag.

This is done by a Sabre ServerPlugin with beforeMethod:* listener which decodes the HTTP_USER_AGENT and a report listener which then tweaks a {DAV:}principal-property-search report request to have the flag set.

TODO

• implement tests

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[rotdrop]

Actually, the delegation dialog and the participants dialog of the OSX calendar app in "Ventura" now finds the principals. Inviting participants seems to work, delegation is still flaky: the delegation is transmitted to the NC server but the OSX calendar app somehow has problems with the response. The web-server access log however only shows

REPORT /remote.php/dav/principals/users/claus/calendar-proxy-write/ HTTP/1.1" 207 1203

when updating the delegation settings.

[rotdrop]

This is done by a Sabre ServerPlugin with beforeMethod:* listener which decodes the HTTP_USER_AGENT and a report listener which then tweaks a {DAV:}principal-property-search report request to have the flag set.

What can be used in place of the asterisk? Parsing the user-agent with a regexp is probably a little bit costly, and here only necessary for the report requests.

[tcitworld]

Thanks, looks great!

[tcitworld]

Do you mind reverting your composer-related changes other than adding the new class in apps/dav/composer/composer/autoload_static.php and the second part of apps/dav/composer/composer/autoload_classmap.php? You likely have a different composer version installed that cause the rest of the changes.

Please squash your commits as well.

[rotdrop]

Do you mind reverting your composer-related changes other than adding the new class in apps/dav/composer/composer/autoload_static.php and the second part of apps/dav/composer/composer/autoload_classmap.php? You likely have a different composer version installed that cause the rest of the changes.

I have probably just a recent composer version installed, which no longer support PHP 5. But for the question: I do not mind at all. However, ideally the Nextcloud core developers would just regenerate the autoload-files with whatever composer version they usually use. I think without the composer changes at least the continuous integration test has no chance to succeed.

Please squash your commits as well.

I do not mind, but isn't this done automatically during merge? Doesn't matter, I'll squash them.

[rotdrop]

Please squash your commits as well.

I do not mind, but isn't this done automatically during merge? Doesn't matter, I'll squash them.

Actually, I would suggest to squash all commits with the exception of the composer changes.

[rotdrop]

Please squash your commits as well.

I do not mind, but isn't this done automatically during merge? Doesn't matter, I'll squash them.

Actually, I would suggest to squash all commits with the exception of the composer changes.

@tcitworld In order to avoid unnecessary work I'll wait for a response from your side. Of course, it is not a problem to just squash all commits in to one, I just think that it makes sense to keep all generated files separate from the real changes.

[tcitworld]

However, ideally the Nextcloud core developers would just regenerate the autoload-files with whatever composer version they usually use.

Yeah, I guess this is done one in a while, but let's not create conflits if we can avoid them.

I do not mind, but isn't this done automatically during merge?

This is not enabled for this repository, not sure why, probably Github drops Sign-off information during squashing.

Addressed

[rotdrop]

Do you mind reverting your composer-related changes other than adding the new class in apps/dav/composer/composer/autoload_static.php and the second part of apps/dav/composer/composer/autoload_classmap.php? You likely have a different composer version installed that cause the rest of the changes.

Please squash your commits as well.

I have just also squashed the composer changes into the remaining single commit.

[labor4]

Are there intentions to backport to NC 26 ?

[z3ky]

Does this plugin still works? If yes, how do I activate it?

[JohnPritchard]

I am brand spanking new to NextCloud, I have just completed installation for the first time. I'm running Nextcloud Hub 9 (30.0.1) -- which I assume means I'm running NextCloud 30.0.1.
Is this "plugin" still relevant? How do I install/enable it?
Many thanks in advance for any help and/or advice.

[labor4]

I am brand spanking new to NextCloud, I have just completed installation for the first time. I'm running Nextcloud Hub 9 (30.0.1) -- which I assume means I'm running NextCloud 30.0.1. Is this "plugin" still relevant? How do I install/enable it? Many thanks in advance for any help and/or advice.

This is not a plugin but a code change. It has been implemented. DAV is core functionality. In this case a fix for the "Calendar" app.

[JohnPritchard]

That's great news!
Indeed I can connect to my NextCloud Calendar Server from macOS (15 == Sequoia) and iOS (18). I see events created via the webUI in macOS and iOS and vice versa.
But unfortunately I am still having trouble setting up delegates, can I/should I report the issues here? Or there somewhere else I should make an Issue/bug report/...

[labor4]

That's great news! Indeed I can connect to my NextCloud Calendar Server from macOS (15 == Sequoia) and iOS (18). I see events created via the webUI in macOS and iOS and vice versa. But unfortunately I am still having trouble setting up delegates, can I/should I report the issues here? Or there somewhere else I should make an Issue/bug report/...

This issue is closed and outdated.

When you think there is still a problem, create a new bug report/issue.

btw. in the meantime: apple is notorious for bending even their own standards. you can delegate via the nextcloud web interface, which will reflect back to apple calendar app. but your contribution is helpfull, so when you describe the symptoms/observations closely and post a report, thats the right way to confront this problem.

another btw: if you are going to deal with this specific issue, if you can, its a good idea to include the webservers access.log entries in the report, that apple calender triggers during your attempt.

[JohnPritchard]

Hi labor4,
Thanks for the clear instructions...
I can easily appreciate that it is caused by Apple bending... it is also entirely possible I've not got everything quite right, I just spent several hours getting my half-working SSL certificate verification working 100% -- I had to provide the SSLCACertificateFile of my certificate provider, which I hadn't realised.

In the meantime, it would be great if I can set up delegatation via the nextcloud web interface, but I've not been able to find that, would you be so kind as to point me in the right direction?

In any case, many thanks for your help and assistance.
J

[rotdrop]

Hi labor4, Thanks for the clear instructions... I can easily appreciate that it is caused by Apple bending... it is also entirely possible I've not got everything quite right, I just spent several hours getting my half-working SSL certificate verification working 100% -- I had to provide the SSLCACertificateFile of my certificate provider, which I hadn't realised.

In the meantime, it would be great if I can set up delegatation via the nextcloud web interface, but I've not been able to find that, would you be so kind as to point me in the right direction?

In any case, many thanks for your help and assistance. J

Nope, AFAIK this is still not exposed in the web interface, though it should be supported by the calendar backend. See here:

nextcloud/calendar#2706

[labor4]

thanks

given said issue (still valid?), we maybe speak of different technical things.

i tested it a while ago and „shared“ a cal to another user in web, and found it to be handed down to apple calender, seemingly in a way that was transparent (as in „does not know“) to the client. how this really differentiates against a proper „caldav delegation“ i do not know.

i did have the (unproven) suspicion that this may be a „dontworry“ replacement method for this need that works better. same way NC finally ditched the apple-specific calendar-invitation chaos and went the more cross/stable google-way with mails and links. but thats just my guts speaking. 🙏😁

carefull testing for usability by the user is advised, i guess.

sorry. dont know more.

is there an arguement that „sharing a calendar in some way or meaning internally via web to another user“ is not possible?

[rotdrop]

thanks

given said issue (still valid?), we maybe speak of different technical things.

i tested it a while ago and „shared“ a cal to another user in web, and found it to be handed down to apple calender, seemingly in a way that was transparent (as in „does not know“) to the client. how this really differentiates against a proper „caldav delegation“ i do not know.

i did have the (unproven) suspicion that this may be a „dontworry“ replacement method for this need that works better. same way NC finally ditched the apple-specific calendar-invitation chaos and went the more cross/stable google-way with mails and links. but thats just my guts speaking. 🙏😁

carefull testing for usability by the user is advised, i guess.

sorry. dont know more.

"delegation" means that you let someone else edit your calendars on behalf of yourself, you remain the organizer. It is not visible that it wasn't you who edited things. The use case is e.g. when "the big boss" delegates his calendars to a clerk who manages his appointments.

This is different from a shared writable calendar, here the person who creates an event is the organizer which then in general is different from the owner of the calendar.

And yes: if you share a calendar to someone else then this calendar will appear in that other ones caldav collection and is visible through the caldav protocol.

And yes: the issue a mentioned in my previous post is still valid, it is still not possible to manage calendar delegation in the frontend.