[Bug]: Cancelling single instance in a recurring series

[section1]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

This is a copy of a close issue : nextcloud/calendar#7057

The issues are mostly in the nextcloud/server code, but I am posting here as logically this is Calendar functionality and most users will search calendar issues first.

Actual behavior

A iTip message is generated but the message wrongly sets the CANCELLED status on the base event.
Inbound iTip message processing wrongly applies the CANCELLED status to the base event and not a instance.
Due to the above the iMip message shows the entire event cancelled.

Steps to reproduce

1. Create a recurring event
   2, Cancel a single instance using the Status in the editor (Do not use delete)

Expected behavior

1 A iTip message should be generated with only the instance cancelled.
2 A iMip message should be sent to participants stating the instance has been updated and an instance has been cancelled. (This debatable, if one or two message should be sent. Technically I think it should be two, one UPDATE for the base event and one CANCEL for the newly created instance as these are technically two separate actions.)

Actual behavior

1 A iTip message is generated but the message wrongly sets the CANCELLED status on the base event.
2 Inbound iTip message processing wrongly applies the CANCELLED status to the base event and not a instance.
3 Due to the above the iMip message shows the entire event cancelled.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

[section1]

Found other related case: nextcloud/calendar#6655

[section1]

I take sometime testing this real annoying problem and created a patch with the help of a good LLM.
I make multiple test canceling using "STATUS: Cancel"(the problematic one) and EXDATE and works fine.
Too i tested using an external calendar(using ics via email).

Please can a real dev check this patch and maybe create a PR ?
I think too that possible to fix this at the sabre side.

PD this patch is tested in version 32.x
PD2 i keep the commentaries generated by the LLM to have an idea what is doing..

thanks

Sabre's parseEventInfo() walks every VEVENT in the calendar object and
unconditionally copies STATUS into the series-level $eventInfo['status'].
When an organizer cancels a single instance of a recurring event, the
calendar object ends up with a master VEVENT (with RRULE, no STATUS) plus
an override VEVENT (with RECURRENCE-ID and STATUS:CANCELLED). The override
leaks its CANCELLED status into $eventInfo['status'], which has two
observable consequences:

1. Organizer -> attendee (parseEventForOrganizer, overridden in our
   TipBroker): the guard

       if (!$attendee['newInstances'] || $eventInfo['status'] === 'CANCELLED') {

   falls into the CANCEL branch and emits METHOD:CANCEL for the whole
   series (RRULE, no RECURRENCE-ID), cancelling the full event for every
   attendee instead of just the one instance.

2. Attendee -> organizer (parseEventForAttendee in Sabre's parent Broker):
   the early return

       if ('CANCELLED' === $eventInfo['status']) { return []; }

   silently drops REPLY messages. Consequence: after an organizer cancels
   one instance, any subsequent attendee action on a *different* instance
   (e.g. declining week 3 after week 2 was cancelled) never produces a
   REPLY to the organizer.

--- a/apps/dav/lib/CalDAV/TipBroker.php
+++ b/apps/dav/lib/CalDAV/TipBroker.php
@@ -92,11 +92,22 @@ class TipBroker extends Broker {
                        foreach ($calendar->select('VTIMEZONE') as $timezone) {
                                $icalMsg->add(clone $timezone);
                        }
+                       // Derive the series-level status strictly from the master VEVENT.
+                       // $eventInfo['status'] is populated by Sabre's parseEventInfo() from
+                       // any VEVENT in the calendar object (including cancelled overrides),
+                       // so it cannot be trusted to represent the status of the whole
+                       // series: a cancelled override would otherwise trigger a full-event
+                       // CANCEL to all attendees instead of the expected per-instance
+                       // cancellation (re-sent as REQUEST with the cancelled exception).
+                       $masterEvent = $eventInfo['instances']['master'] ?? null;
+                       $masterStatus = ($masterEvent !== null && isset($masterEvent->STATUS))
+                               ? strtoupper((string)$masterEvent->STATUS->getValue())
+                               : null;
                        // If there are no instances the attendee is a part of, it means
                        // the attendee was removed and we need to send them a CANCEL message.
                        // Also If the meeting STATUS property was changed to CANCELLED
                        // we need to send the attendee a CANCEL message.
-                       if (!$attendee['newInstances'] || $eventInfo['status'] === 'CANCELLED') {
+                       if (!$attendee['newInstances'] || $masterStatus === 'CANCELLED') {
 
                                $message->method = $icalMsg->METHOD = 'CANCEL';
                                $message->significantChange = true;
@@ -188,4 +199,26 @@ class TipBroker extends Broker {
                return $messages;
        }
 
+       /**
+        * This method is used to generate REPLY messages from an attendee back to
+        * the organizer.
+        *
+        * Sabre's parent implementation bails out when $eventInfo['status'] is
+        * 'CANCELLED'. That status is populated by parseEventInfo() from any
+        * VEVENT in the calendar object, so a cancelled recurrence override leaks
+        * its status into the series-level value and causes attendee-side updates
+        * (e.g. declining a different instance) to be dropped silently. We
+        * re-derive the status strictly from the master VEVENT before delegating.
+        *
+        * @param string $attendee
+        * @return \Sabre\VObject\ITip\Message[]
+        */
+       protected function parseEventForAttendee(VCalendar $calendar, array $eventInfo, array $oldEventInfo, $attendee) {
+               $masterEvent = $eventInfo['instances']['master'] ?? null;
+               $eventInfo['status'] = ($masterEvent !== null && isset($masterEvent->STATUS))
+                       ? strtoupper((string)$masterEvent->STATUS->getValue())
+                       : null;
+               return parent::parseEventForAttendee($calendar, $eventInfo, $oldEventInfo, $attendee);
+       }
+
 }

Sabre side patch (i did basic tests with this patch)

--- a/3rdparty/sabre/vobject/lib/ITip/Broker.php
+++ b/3rdparty/sabre/vobject/lib/ITip/Broker.php
@@ -888,7 +888,7 @@ class Broker
                 }
                 sort($rrule);
             }
-            if (isset($vevent->STATUS)) {
+            if (isset($vevent->STATUS) && !isset($vevent->{'RECURRENCE-ID'})) {
                 $status = strtoupper($vevent->STATUS->getValue());
             }

[section1]

Today i did more testing ONLY with the patch(2nd one) that only change on line in Sabre Broker.php file and with one organizer and one attendee i can't find any problem... maybe that patch is the "better" solution.