CalDAV (Kerio): Recurring events with single events moved to another date, are not shown in Cal.com

[saschafoerster]

Issue Summary

Recurring events, when edited later so that one of the second or later events is moved out of the row, will not be visible in the availabilities. Addition to #3457

Steps to Reproduce

1. Create a weekly recurring event in Kerio (tested with web interface and Apple Calendar)
2. Move one of the entries to another date (for instance move the second entry from Wednesday to Tuesday)
3. The moved event will not be shown as booked in Cal.com availabilities.

Also recurring events, that are moved around, should be removed from Cal.com availabilities.

Technical details

• Kerio (and webinterface): 10.0.1
• MacOS 13.3.1
• Apple Calendar connected via CalDAC
• Microsoft Outlook for Mac, connected via Exchange
• @alishaz-polymath has more details from the CalDAV-logs. Needs to check, how recurring events with single items edited are shown in CalDAV.

[alishaz-polymath]

As we explored this over the call, it's clearly a non-standard way of representing the change. I tried to recreate it again locally, however, I couldn't find the X-NEXT-ALARM property this time around, which suggests that it isn't reliable for two reasons:

1. It isn't a standard in iCalendar 2.0
2. It is an internal/custom variable of which we would have very little to no idea.

Here's what happens in the standard iCalendar 2.0 way:

When you have a recurring event and you move one of the instances to another date, CalDAV handles this by creating an exception to the recurring event. This is done by adding an "EXDATE" (Exception Date) property to the recurring event and a new separate event for the moved instance.

Here's an overview of what happens:

The original recurring event (VEVENT) will have a property called "RRULE" (Recurrence Rule) that defines the recurrence pattern.
When you move one instance of the recurring event to a different date, an "EXDATE" property is added to the original VEVENT, with the date of the moved instance. This tells the calendar application that this specific instance of the event should be excluded from the recurrence pattern.
A new VEVENT is created with a unique UID (Unique Identifier) for the moved instance. This new event will have the same properties as the original event (such as SUMMARY, LOCATION, etc.), but it will have a different DTSTART (start date) and DTEND (end date) to reflect the new date.
Optionally, the new VEVENT might also have a "RECURRENCE-ID" property, which refers to the original date of the moved instance in the recurring event. This property is used by some calendar applications to link the new event to the original recurring event.

After these changes, you can expect the following:

- The moved instance of the recurring event will no longer be part of the original recurrence series.
- The original VEVENT will have an EXDATE property with the date of the moved instance.
- A new VEVENT with a unique UID will be created for the moved instance, having the new date and time.

The CalDAV clients will then update the calendar objects accordingly to display the exception and the new event at the correct date and time.

Now, the biggest issue in the aforementioned problem is, we never receive the ICal object for the changed event. Thus, at this stage, I don't think we would be able to accommodate this as it is a non-standard way of dealing with this scenario and we do not have enough knowledge around how it is being dealt with internally at Kerio. I think we need to figure out why we're not receiving the updated event in this situation to begin with, and that should probably start at Kerio 🙏

[kvdb]

I also have problems with recurring events that have been moved since the initial event. Running Mailcow/SOGo. If I can be of assistance sharing any (ical) files, I'll happily cooperate through private communciation.

[alishaz-polymath]

Hey @kvdb as mentioned above, the issue with Kerio is that the new events aren't a part of the ICAL anymore. If you can create a test account for me,I'd be able to take a closer look what's going on in your case. You can email me the test account credentials at: ali@cal.com

[kvdb]

@alishaz-polymath and me tried to reproduce the issue, seems it wasn't possible back then. So what we couldn't do was create a recurring event, fiddle with it in SOGo until it didn't show up as blocked in cal.com. However, perhaps @alishaz-polymath you can investigate with a recurring event in my calendar on the 16th of april which shows up as free on cal.com at the moment? I case you're up for one more try, I re-enabled your test email account in my environment. But screensharing while I access my account might be more useful?

[kvdb]

I just tried Thunderbirds appointment.day (beta program) and their caldav connector does it correctly. Since both cal.com and Thunderbird appointment are open source, perhaps best practices can be shared.