SchedulingPlugin reset attendee participation state on significant event change

[onny]

Reset attendee participation state to "NEEDS-ACTION" if change to an existing event is significant.

Currently this PR does fix an issue described in #1282 where an accepted invitation of an attendee stays accepted even if the organizer changes the event date.

Unfortunately accepting the changed event doesn't seem to work. At least the attendee state in Nextcloud remains on "pending approval".

Todo

• fix reapproval to event
• consider writing a test case for this
• add significantChangeRFC-6638-3_2_8 to ITIP/Message object

[onny]

@georgehrke @miaulalala I'm a bit lost here. With this PR, the attendee PARTSTAT gets reset to NEEDS-ACTION after an event update. This is visible in the calendar app and also in the ics-file export.
An updated invitation mail gets send again.
Now accepting the updated event isn't possible anymore. It does say "participation updated sucessfully" in the browser window but participation state remains NEEDS-ACTION.
The function scheduleLocalDelivery in 3rdparty/sabre/dav/lib/CalDAV/Schedule/Plugin.php does process the updated caldav data with PARTSTAT=ACCEPTED but not sure where it goes and why it doesn't appear in the calendar :(

[miaulalala]

Hi onny, I think this might have to do with nextcloud and not sabre. Can you check the ics in the database table oc_calendarobjects to determine if this is limited to the frontend or of the calendarobject itself doesn't get updated?

[onny]

@miaulalala Thank you for the hint, this was quite interesting to look into. In case there's an additional attendee assigned to an calendar event, a second object gets created in the database. When accepting the invitation, the PARTSTAT value gets updated in both objects. After a significant event update, only the second object falls back to PARTSTAT=NEEDS-ACTION

1|BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.4.2//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
CREATED:20230309T115241Z
LAST-MODIFIED:20230309T115607Z
SEQUENCE:3
UID:618f4388-dc29-4a26-b82d-2ee7ff46ef49
DTSTART;VALUE=DATE:20230311
DTEND;VALUE=DATE:20230312
STATUS:CONFIRMED
SUMMARY:testinvite
ATTENDEE;CN=user1;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT;
 LANGUAGE=en:mailto:user1@localhost
ORGANIZER;CN=admin:mailto:admin@localhost
DTSTAMP:20230309T115609Z
END:VEVENT
END:VCALENDAR
|sabredav-e7f0157c-1e79-433e-a144-2dd97ee42fa9.ics|3|1678362969|ec2874ecbde6f30163bdcb093396c843|522|VEVENT|1678492800|1678579200|618f4388-dc29-4a26-b82d-2ee7ff46ef49|0|0|
2|BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//IDN nextcloud.com//Calendar app 4.3.0-alpha.1//EN
BEGIN:VEVENT
CREATED:20230309T115241Z
DTSTAMP:20230309T115607Z
LAST-MODIFIED:20230309T115607Z
SEQUENCE:3
UID:618f4388-dc29-4a26-b82d-2ee7ff46ef49
DTSTART;VALUE=DATE:20230311
DTEND;VALUE=DATE:20230312
STATUS:CONFIRMED
SUMMARY:testinvite
ATTENDEE;CN=user1;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
 ANT;LANGUAGE=en;SCHEDULE-STATUS=1.1:mailto:user1@localhost
ORGANIZER;CN=admin:mailto:admin@localhost
END:VEVENT
END:VCALENDAR
|44B5ECA1-CF3E-48F9-98A1-42DF9F7A723A.ics|1|1678362970|235c7bd8dad636120345805c6ca73eb4|565|VEVENT|1678492800|1678579200|618f4388-dc29-4a26-b82d-2ee7ff46ef49|0|0|

Even when accepting again the second invitation, the PARTSTAT of the second calendar object remains at NEEDS-ACTION.

I'm not quite sure yet why there are two objects, if both needs to get updated and how to access them.

[onny]

Oh I see the one calendar object with the calendar-id 1 belongs to the user admin which is the organizer in my test setup. The PARTSTAT value doesn't get updated for the calender object which belongs to the invited user user1 with the calendar id 3. Not sure how to set PARTSTAT for all calendarobjects and attendees

[miaulalala]

Hi onny, I'm still catching up on things after my hols but this is what it sounds like to me off the top of my head: The delivery should handle the new partstats for all attendees, but it might be dropped somewhere along the way, I've seen that before with accepted invitations. \Sabre\CalDAV\Schedule\Plugin::scheduleLocalDelivery and maybe look into what type of iTip request it is - if it's a REQUEST it uses a different logic than the REPLY for example. Will dig into this a bit further when I have some time :)

[onny]

Thank you for the replay, haven't managed yet to catch all iTip messages and set PARTSTAT=NEEDS-ACTION for all participants/calendarobjects.

But I confirmed that in theory resetting this property in case of a event update works. I manually set PARTSTAT=NEEDS-ACTION for all calendarobjects in the database. After that accepting the the updated invitation works as expected:

It does not work if not all PARTSTATS gets resetted for all calendarobjects.

Sorry if this sounds complicated ^^ Just have to get

$attendee['PARTSTAT'] = "NEEDS-ACTION";

work for all attendees.

[onny]

Would be happy if someone could give me some advice on how to update the PARTSTAT property on all calendar objects belonging to local organizer and local attendees :) @LukasReschke @DeepDiver1975

[onny]

@miaulalala The PARTSTAT property gets set to NEEDS-ACTION for both, organizer and attendee calendarobject if I put this loop to the beginning of processICalendarChange to manipulate $newObject

protected function processICalendarChange($oldObject, VCalendar $newObject, array $addresses, array $ignore = [], &$modified = false)
{
    $broker = new ITip\Broker();

    foreach ($newObject->VEVENT->ATTENDEE as $attendee) {
        $attendee['PARTSTAT'] = "NEEDS-ACTION";
    }

    $messages = $broker->parseEvent($newObject, $addresses, $oldObject);

    if ($messages) {
        $modified = true;
    }

It is not possible to manipulate $newObject for the attendee after the $messages object gets constructed.

You also mentioned different iTipMessage methos, so I added an additional REQUESTmethod to the end of scheduleLocalDelivery function:

if ($isNewNode) {
    $calendar = $this->server->tree->getNodeForPath($calendarPath);
    $calendar->createFile($newFileName, $newObject->serialize());
} else {
    // If the message was a reply, we may have to inform other
    // attendees of this attendees status. Therefore we're shooting off
    // another itipMessage.
    if ('REPLY' === $iTipMessage->method) {
       $this->processICalendarChange(
           $oldICalendarData,
           $newObject,
           [$iTipMessage->recipient],
           [$iTipMessage->sender]
       );
    } elseif ('REQUEST' === $iTipMessage->method) {
       $this->processICalendarChange(
           $oldICalendarData,
           $newObject,
           [$iTipMessage->recipient],
           [$iTipMessage->sender]
       );      
    }
    $objectNode->put($newObject->serialize());

This fires several processICalendarChange function calls (depending on how many attendees get assigned). Unfortunately in subsequent calls, the $messages object is empty in processICalendarChange function.

[miaulalala]

There's the $iTipMessage->significantChange property which could be helpful. You could check the iTipMessage for this to see if the change is significant enough to warrant the resetting of the PARTSTAT. Not every change will fall into this category.