Recurring events from caldav server not blocked

[m4tze]

Found a bug? Please fill out the sections below. 👍

Issue Summary

I am running the docker version of calcom and I have two caldav backends configured for my user. There are many recurring events in my calendar and none of these is blocked. Normal (one-time) events are blocked as they should.

Steps to Reproduce

1. start docker version
2. run a caldav server, e.g. radicale and create recurring events
3. import calendar into calcom
4. go to booking
5. realize, that blocked dates are still available

I think this is a bug, as recurring events should block the corresponding dates

[milospuac]

Thanks for sharing this, our team will investigate the issue

[sr-verde]

Yeah, would be a necessary feature for me as well. Thank you!

[afoster]

I'm also seeing this with a Zimbra caldav backend.

[m4tze]

There seem to be some ongoing development regarding recurring events: https://github.com/calcom/cal.com/tree/leog/recurring-event-improvements - maybe @leog can confirm?

[leog]

Hi there! Indeed, I'm working on some improvements for recurring events.
@m4tze If I understand correctly, this is related to recurring events created outside Cal that are not correctly taken into consideration when blocking available time?

[m4tze]

@leog thanks for getting into this. Yes, it is related to recurring events created in Thunderbird / Android Calendar / Apple Calendar and synced via caldav (radicale and Zimbra as backends). These dates are not blocked.

[leog]

my pleasure @m4tze! and to be clear, any other type of event in that flow is behaving as expected, right? just to be sure it is scoped to recurring events

[m4tze]

@leog I can confirm, that other entries (non recurring) behave as expected, they block the time for selection.

[leog]

@m4tze I can't seem to be able to reproduce the issue. Got myself radicale locally and Thunderbird to manage a calendar, created two events for one day, one regular and one recurring, and they are showing up as expected in the "Availability" tool to troubleshoot these scenarios, under your schedule. I'm assuming you have toggled your calendar in the Installed Apps configuration page to let Cal check specific calendars for conflicts. Any other information I might be missing? Happy to help.

[m4tze]

@leog I investigated this a bit. It works when I start calcom baremetal on my machine. It does not work for the version built for Docker. I also changed the Dockerfile to use the sources form the productive branch, but this does not work. I do not see a difference between the Docker version and the baremetal install. Have you tried the Docker version or did you try this in your developer setup? Is this something related to outdated dependencies?

[m4tze]

@leog @milospuac this seems to be a timezone issue for recurring events. I further tried to find the failure and fortunately, I recognized the times blocked and saw, that the timezone of the recurring event itself is wrong (and thus, fell out of my usual business times) and was not blocked because of this. After changing the timezone in the Docker container, the times are successfully blocked. I cannot tell, where the problem with the timezone of the recurring event comes from (= whether the recurring event is wrong or the library implementation parsing it). Could you confirm this with your test setting?

[m4tze]

I extracted the calendar entry, maybe there is a problem interpreting the vtimezone information?! To me it looks correct.

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETTO:+0100
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:344856ce-4c83-4e23-9e57-6f413ae23010
RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR
SUMMARY:Daily Stand-up
DESCRIPTION:description redacted
LOCATION:location redacted
X-MOZ-RECEIVED-SEQUENCE:0
X-MOZ-RECEIVED-DTSTAMP:20220315T083616Z
X-MOZ-INVITED-ATTENDEE:mailto:redacted@example.com
ORGANIZER:mailto:redacted@example.com
DTSTART;TZID="Europe/Berlin":20220311T093000
DTEND;TZID="Europe/Berlin":20220311T100000
STATUS:CONFIRMED
CLASS:PUBLIC
TRANSP:OPAQUE
LAST-MODIFIED:20220315T141935Z
DTSTAMP:20220315T141935Z
SEQUENCE:0
END:VEVENT
END:VCALENDAR