cal.com
cal.com copied to clipboard
calcom
Availability fetching is bugged (atleast for CalDAV)
Issue Summary
So, I found a weird one while trying to debug CalDAV (but Iām not sure if this one is limited to CalDAV or spreads across other integrations as well)
When we book a slot in one of the event types, only that slot within that specific event type is blocked, but other event types still have the slots during that booked time available. Note that the booking was made at the CalDAV calendar as well, yet I think the freebusy data fetched from it was empty.
Steps to Reproduce
Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
Technical details
Integration in use: CalDAV
Currently, we only look at the event type for bookings to block out the slots for that specific event type, which isn't very useful for blocking out slots on other event types (in the fallback calendar :: no integration). I think we'd need to improve this.
Removed assignees until we start work (as so not to block others that may want to pick this up before us @alishaz-polymath)
I've identified exactly where the issue is, the ICAL parser is unable to parse the CalendarObject data (ICalstring) because of the apparent incompatibility between the two items. The ICAL parser expects data like:
BEGIN:VCALENDAR\r
VERSION:2.0\r
CALSCALE:GREGORIAN\r
PRODID:adamgibbons/ics\r
X-PUBLISHED-TTL:PT1H\r
METHOD:PUBLISH\r
X-CALENDARSERVER-ACCESS:PUBLIC\r
BEGIN:VEVENT\r
UID:06436a27-4991-4c1e-ae44-d86af6a8818f\r
SUMMARY:30min between Pro Example and Test\r
DTSTAMP:20220817T060100Z\r
DTSTART:20220818T093000Z\r
DESCRIPTION:What:\\n30min\\n \\n\\nInvitee Time Zone:\\nAsia/Calcutta\\n \\n\\nWho\r
:\\n\\nPro Example - Organizer\\[email protected]\\n \\nTest\\[email protected]\\n \\n \r
\\nWhere:\\n\\n\\n\\n\\n\\nNeed to reschedule or cancel?\\nhttp://localhost:3000/cancel/hzwhM1MgW89q83kahDpev6\r
ORGANIZER;CN=\"Pro Example\":mailto:[email protected]\r
ATTENDEE;CN=Test;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:[email protected]\r
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=\"Pro Example\";CUTYPE=INDIVIDUAL:mailto:[email protected]\r
DURATION:PT30M\r
TRANSP:OPAQUE\r
X-MICROSOFT-CDO-BUSYSTATUS:BUSY\r
BEGIN:VALARM\r
UID:67339227-c4e8-4770-ab96-dd0c8c22ee77\r
TRIGGER;VALUE=DATE-TIME:19760401T005545Z\r
ACTION:NONE\r
END:VALARM\r
END:VEVENT\r
END:VCALENDAR
While the data provided by TSDAV's fetchCalendarObjects function has the following structure:
BEGIN:VCALENDAR\rVERSION:2.0\rCALSCALE:GREGORIAN\rPRODID:adamgibbons/ics\rX-PUBLISHED-TTL:PT1H\rMETHOD:PUBLISH\rX-CALENDARSERVER-ACCESS:PUBLIC\rBEGIN:VEVENT\rUID:06436a27-4991-4c1e-ae44-d86af6a8818f\rSUMMARY:30min between Pro Example and Test\rDTSTAMP:20220817T060100Z\rDTSTART:20220818T093000Z\rDESCRIPTION:What:\\n30min\\n \\n\\nInvitee Time Zone:\\nAsia/Calcutta\\n \\n\\nWho\r :\\n\\nPro Example - Organizer\\[email protected]\\n \\nTest\\[email protected]\\n \\n \r \\nWhere:\\n\\n\\n\\n\\n\\nNeed to reschedule or cancel?\\nhttp://localhost:3000/cancel/hzw\r hM1MgW89q83kahDpev6\rORGANIZER;CN=\"Pro Example\":mailto:[email protected]\rATTENDEE;CN=Test;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:[email protected]\rATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=\"Pro Example\";CUTYPE=INDIVIDUAL:mailto:[email protected]\rDURATION:PT30M\rTRANSP:OPAQUE\rX-MICROSOFT-CDO-BUSYSTATUS:BUSY\rBEGIN:VALARM\rUID:e845d3c7-2786-4dad-8f8a-42f98ac9eac6\rTRIGGER;VALUE=DATE-TIME:19760401T005545Z\rACTION:NONE\rEND:VALARM\rEND:VEVENT\rEND:VCALENDAR
In other words, the expected input for the ICAL.parse() function is a well structured ical object (perhaps the EOL is somehow already defined with other than just \r, which seems to be the difference between the two š¤ )
Just replacing all the \r with \r\n now fixes this initial incompatibility issue but reveals even more incompatibility in the code. Work in progress āļø