Accept or decline all future recurrences

[st3iny]

Is your feature request related to a problem? Please describe.

I was invited to a recurring meeting and would like to accept all future invitations. However, I can only react to a single recurrence at a time in the Calendar app.

Describe the solution you'd like

I would like to be able to accept or decline all future recurrences. To have similar buttons to updating all future recurrences of an event.

For example, Thunderbird has separate buttons to either accept a single recurrence or all future ones.

Describe alternatives you've considered

Accept or decline each recurrence manually.

Additional context

Follow-up to #3864

[SebastianKrupinski]

Confirmed.

Pressing accept in the UI creates a new modified instance instead of accepting the base event.

BEGIN:VEVENT
CREATED:20250205T132026Z
DTSTAMP:20250205T132137Z
LAST-MODIFIED:20250205T132137Z
SEQUENCE:3
UID:96c1fd7b-03d1-4646-b508-0ccb91e7508a
DTSTART;TZID=America/Toronto:20250211T100000
DTEND;TZID=America/Toronto:20250211T110000
STATUS:CONFIRMED
SUMMARY:This is a recurring test
RRULE:FREQ=WEEKLY;COUNT=12;BYDAY=TU,TH,SA
ATTENDEE;CN=User 2;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT;RSVP=TRUE;LANGUAGE=en;SCHEDULE-STATUS=1.1:mailto:user2@redacted
ORGANIZER;CN=User 1:mailto:user1@redacted
END:VEVENT

BEGIN:VEVENT
CREATED:20250205T132026Z
DTSTAMP:20250205T132137Z
LAST-MODIFIED:20250205T132137Z
SEQUENCE:3
UID:96c1fd7b-03d1-4646-b508-0ccb91e7508a
DTSTART;TZID=America/Toronto:20250211T100000
DTEND;TZID=America/Toronto:20250211T110000
STATUS:CONFIRMED
SUMMARY:This is a recurring test
ATTENDEE;CN=User 2;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT
 ;RSVP=TRUE;LANGUAGE=en;SCHEDULE-STATUS=1.1:mailto:user2@redacted
ORGANIZER;CN=User 1:mailto:user1@redacted
RECURRENCE-ID;TZID=America/Toronto:20250211T100000
END:VEVENT

[st3iny]

Pressing accept in the UI creates a new modified instance instead of accepting the base event.

Makes sense for the current button to accept a single recurrence and thus create a new instance, right?

[SebastianKrupinski]

Makes sense for the current button to accept a single recurrence and thus create a new instance, right?

Yes and no, from a technical point of view yes, accepting a single instance should make a new modified instance in the event. But from a user point of view no, it would be confusing to the user.

I would almost say that we should have a secondary confirmation, box with 3 buttons "Accept Entire Series / Accept Only (date of current selected instance) / Accept all dates after (date of current selected instance)".

As for the technical part the buttons show perform the following function,

• Accept Entire Series - Should accept the base event
• Accept Only - Should make an instance with participation status for the user (not sure how existing part status should be handled for other users)
• Accept all dates after - Should make an instance with participation status for the user and modified RRULE and RDATE's for all dates after the selected date.

The issue is, will other clients handle the modified instances properly and how will the events be displayed. Currently I believe most other software applies the participant status to all instance that the user is part of (But this would need to be tested). From a RFC point of view I believe the attendees are not allowed to modify the original event, which would mean that responding to a event with a modified instance would violate this rule.

https://datatracker.ietf.org/doc/html/rfc5546#section-3.2.3

[SebastianKrupinski]

Found it... In iTIP messages, only the "Organizer" is authorized to modify or cancel calendar entries they organize.

https://datatracker.ietf.org/doc/html/rfc2447#section-2.2.1

Knowing this,

A, the event cannot be modified when accepting/declining an event.
B. the UI should be read only for events that do not belong to the user.
C. any REPLY messages should be stripped of all other information except for a single attendee line with the PART STATUS.
D. unrelated to this, but processing inbound REPLY messages should ignore everything but the PART STATUS

[SebastianKrupinski]

More RFC information on Recurrence Instances

https://datatracker.ietf.org/doc/html/rfc5546#section-3.7.1

[nimishavijay]

As discussed in design review call

• Use modal like gcal
• Instead of "OK" use either accept or decline
• Instead of "RSVP to" use either accept or decline

Also use the same pattern while updating a recurring event

• Instead of "Edit" use "Update"
• Instead of "OK" use "Update"