Updating a single item in a recurring event does not update the change properly

[0xFurqan]

Steps to reproduce

1.Create a recurring event for 10:00am - 11:00am that repeats daily for 1 week.
2.Edit and change the time to 10:30am - 11:30am for the second occurrence in the series using the “update this occurrence” button.
3.Save

Expected behavior

The change in time of the edited second occurrence from 10:00am-11:00am to 10:30am-11:30am should be properly updated in Google calendar.

Actual behaviour

When we create a recurring event which repeats daily for 1 week. The SEQUENCE number of the generated initial ICS is 2.

When we edit the second occurrence in the recurring event , the generated VEVENT has the same UID of parent and SEQUENCE of 1.

Now the parent event has higher SEQUENCE (2) than the edited occurrence .

Since the edited occurrence has a lower SEQUENCE (1) , the edited occurrence is not getting properly updated in Google calendar.

The edited occurrence should have a higher SEQUENCE number than the parent event and the initial ICS which created the recurring event must be having a SEQUENCE of 0 since it is the first event before any update.

Calendar app version

4.1.0

CalDAV-clients used

Google Calendar

Browser

Firefox 106.0.2

Client operating system

Ubuntu 20.04.5 LTS

Server operating system

Ubuntu 20.04.5 LTS

Web server

Apache

Database engine version

MySQL

PHP engine version

PHP 7.4

Nextcloud version

26.0.0.1

Updated from an older installed version or fresh install

Fresh install

List of activated apps

- calendar: 4.1.0-rc.1
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contactsinteraction: 1.7.0
  - dashboard: 7.6.0
  - dav: 1.25.0
  - federatedfilesharing: 1.16.0
  - federation: 1.16.0
  - files: 1.21.1
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.0
  - lookup_server_connector: 1.14.0
  - oauth2: 1.14.0
  - provisioning_api: 1.16.0
  - settings: 1.8.0
  - sharebymail: 1.16.0
  - systemtags: 1.16.0
  - theming: 2.1.1
  - twofactor_backupcodes: 1.15.0
  - updatenotification: 1.16.0
  - user_status: 1.6.0
  - weather_status: 1.6.0
  - workflowengine: 2.8.0

Nextcloud configuration

No response

Web server error log

No response

Log file

No response

Browser log

No response

Additional info

No response

[ChristophWurst]

@st3iny is this known?

[st3iny]

Not that I know of. I'll try to reproduce it.

[ChristophWurst]

My bad. It sounded like one of the other recurrence bug reports.

[st3iny]

I was able to reproduce it. Editing another occurrence in the set also sets its sequence number to 1.

[0xFurqan]

While looking through the code in node_modules/@nextcloud/calendar-js/dist/index.esm.js i made some observations regarding this

1. In the createRecurrenceException() function the SEQUENCE is being reset to 0 if 'thisAndAllFuture' is false , and the _significantChange flag is being set to true, thus when generating the ICS the SEQUENCE number is being incremented to 1 due to the undirtify() function.
   So inside createRecurrenceException() when the flag 'thisandAllFuture' is false shouldn't the SEQUENCE be set to an increment value ( previous sequence + 1 ) ?

2. When creating a new event why is the SEQUENCE number 2 ? Went through the code and found that the _significantChange flag is being set to true due to RFC 5546 Section 2.1.4 . But shouldn't a change be considered _significantChange only after the initial event is created and when there is an update in that created event. The code is updating SEQUENCE number even before the new event is being saved by clicking the save button. Maybe the issue is because of a newly created event without any change is having a SEQUENCE of 2 ?

[0xFurqan]

While looking through the code in node_modules/@nextcloud/calendar-js/dist/index.esm.js i made some observations regarding this

1. In the createRecurrenceException() function the SEQUENCE is being reset to 0 if 'thisAndAllFuture' is false , and the _significantChange flag is being set to true, thus when generating the ICS the SEQUENCE number is being incremented to 1 due to the undirtify() function.
   So inside createRecurrenceException() when the flag 'thisandAllFuture' is false  shouldn't the SEQUENCE be set to an increment value ( previous sequence + 1 ) ?

2. When creating a new event why is the SEQUENCE number 2 ? Went through the code and found that the _significantChange flag is being set to true due to RFC 5546 Section 2.1.4 . But shouldn't a change be considered _significantChange only after the initial event is created and when there is an update in that created event. The code is updating SEQUENCE number even before the new event is being saved by clicking the save button. Maybe the issue is because of a newly created event without any change is having a SEQUENCE of 2 ?

1. If we increment the SEQUENCE number instead of setting it to 0 when 'update this occurrence' is clicked i guess we can solve this .
2. In createEvent() and updateCalendarObject() it is incrementing the SEQUENCE number , so we have SEQUENCE 2 before the actual save has happend. We can maintain a flag to check if the calendar object is the first instance by setting it to true and update the flag when the object is first saved to false. And we have to only start incrementing the SEQUENCE number when this flag is false. This way at first save the SEQUENCE number is 0.

@st3iny Can i start developing this and send a PR or is it some other issue ?

[jrester]

I encountered the same issue but with outlook and it seems like only updating the SEQUENCE numbers does not resolve this issue.

I also tried to fix it by simply adjusting the sequence number of the updated event to 2 and 3, but both did not work. Outlook only accepted the event once I removed the additional VEVENT (for the original reoccurrence) and after I incremented the SEQUENCE number for the updated event to 2.

Original .ics (not working)

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 4.4.2//EN CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20231025T104626Z LAST-MODIFIED:20231025T104803Z SEQUENCE:2 UID:a1d578cf-d1f6-4deb-8e8d-b6dbb38bfabc DTSTART;TZID=Europe/Berlin:20231007T100000 DTEND;TZID=Europe/Berlin:20231007T110000 STATUS:CONFIRMED SUMMARY:Test RRULE:FREQ=WEEKLY;BYDAY=SA ATTENDEE;CN=x;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTI ON;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:x ORGANIZER;CN=x:mailto:x DTSTAMP:20231025T104938Z END:VEVENT BEGIN:VEVENT CREATED:20231025T104938Z LAST-MODIFIED:20231025T104938Z SEQUENCE:1 UID:a1d578cf-d1f6-4deb-8e8d-b6dbb38bfabc DTSTART;TZID=Europe/Berlin:20231021T070000 DTEND;TZID=Europe/Berlin:20231021T080000 STATUS:CONFIRMED SUMMARY:Test ATTENDEE;CN=x;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTI ON;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1.1:mailto:x ORGANIZER;CN=x:mailto:x RECURRENCE-ID;TZID=Europe/Berlin:20231021T100000 DTSTAMP:20231025T104938Z END:VEVENT END:VCALENDAR

Working .ics

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 4.4.2//EN CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20231025T104938Z LAST-MODIFIED:20231025T104938Z SEQUENCE:2 UID:a1d578cf-d1f6-4deb-8e8d-b6dbb38bfabc DTSTART;TZID=Europe/Berlin:20231021T070000 DTEND;TZID=Europe/Berlin:20231021T080000 STATUS:CONFIRMED SUMMARY:Test ATTENDEE;CN=x;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTI ON;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1.1:mailto:x ORGANIZER;CN=x:mailto:x RECURRENCE-ID;TZID=Europe/Berlin:20231021T100000 DTSTAMP:20231025T104938Z END:VEVENT END:VCALENDAR

Furthermore, nextcloud itself seems to be confused, as the update mail only shows information about the recurrence but not about the updated event:

As you can see the information is about the 7th October (10AM to 11AM) but the update is indeed for the 14th October (7 AM to 8AM)