feat: add iMip Request Handling

[SebastianKrupinski]

• Ref #8458

Summary

• added iMip request handling to automatically update calendar events

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

CS

[ChristophWurst]

I am not sure if ICalendar is only implemented in the server. There can be apps that implement \OCP\Calendar\ICalendarProvider and return their own implementations of ICalendar. This change would break them until they add isWritable and isShared. See ICreateFromString and IHandleImipMessage. The same trick might be needed here.

[SebastianKrupinski]

Originally I left these to methods out of the Interface and only put them in the implementation but that made psalm grumpy.

ERROR: UndefinedInterfaceMethod - lib/private/Calendar/Manager.php:263:46 - Method OCP\Calendar\ICreateFromString::isWritable does not exist (see https://psalm.dev/181)
ERROR: UndefinedInterfaceMethod - lib/private/Calendar/Manager.php:263:73 - Method OCP\Calendar\ICreateFromString::isShared does not exist (see https://psalm.dev/181)

What if I added these to methods to the psalm ignore list? And left them commented out in the interface with a note for later, that way we can give developers a version or two to implement them?

[ChristophWurst]

That's a hack. Psalm complains rightfully. App developers have the interface as contract. Anything that's not in the interface must not be called, so it would also not be usable in Mail.
If you want to learn more about this, read up on the paradigm program to an interface, not an implementation :)

[SebastianKrupinski]

Done

[st3iny]

I tried to test it locally but it did not work. I sent an invite from another external service, added it to my calendar and then moved the event in the external service. A REQUEST with the new dates was sent and received but the event was not updated.

The problem is that no recipient is added to iMIP messages with method REQUEST in

server/apps/dav/lib/CalDAV/CalendarImpl.php

Lines 237 to 247 in 7a2fe4a

	if ($iTipMessage->method === 'REPLY') {
	if ($server->isExternalAttendee($vEvent->{'ATTENDEE'}->getValue())) {
	$iTipMessage->recipient = $organizer;
	} else {
	$iTipMessage->recipient = $attendee;
	}
	$iTipMessage->sender = $attendee;
	} elseif ($iTipMessage->method === 'CANCEL') {
	$iTipMessage->recipient = $attendee;
	$iTipMessage->sender = $organizer;
	}

This causes the local delivery to fail in https://github.com/nextcloud/3rdparty/blob/b3cc57b68388b68e4d4dcf0ddcd8c7ba455dd840/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L418-L423 because no recipient is set and thus no principal is available.

I think another if/else branch needs to be added to the statement above.

---

Please let me know in case I'm doing something wrong.

[SebastianKrupinski]

I tried to test it locally but it did not work. I sent an invite from another external service, added it to my calendar and then moved the event in the external service. A REQUEST with the new dates was sent and received but the event was not updated.

Okay, I lets talk about it quickly tomorrow. It worked for the two services I used. Might be just the way the external service is sending the message.

[SebastianKrupinski]

Please let me know in case I'm doing something wrong.

Nope, this was my blunder, I somehow overwrote or left out the code changes in CalendarImpl::handleIMipMessage(), I don't remember at this point, its been over a month. Logic is fixed. The fun of working on multiple issues in the same file.

[st3iny]

Tested and works beautifully now. Thanks!

[SebastianKrupinski]

@ChristophWurst should we back port this to 30?

[ChristophWurst]

This PR adds a new API. We generally don't backport these. So it's a no here.