CalDAV integration with Fastmail is generating duplicate, erroneous invitation emails.

[mtnowl]

Issue Summary

created from https://github.com/calcom/cal.com/issues/3457#issuecomment-1581465501, but I am also using Fastmail and seeing the same issues. This is making it so I can't use the integration.

We also use Fastmail and have been seeing some oddities with the cal.com integration. Namely, that participants are receiving multiple calendar invites, which on it's own isn't that big of a deal. However, the Fastmail invites are always in UTC, not in the local time of the cal.com invite.

This is creating a lot of confusion with participants, they keep missing our meetings, not realizing one invite is UTC and one in local time. I spoke with the Fastmail team and they relayed the following notes about cal's specific integration.

1. There is a property (SCHEDULE-AGENT=CLIENT) a CalDAV client can add to the event that would prevent CalDAV servers from sending invitations. It appears cal.com is not setting this property even though they are sending an invitation.
2. The invitation being sent by cal.com is using a different UID. Basically every event has a UID that uniquely identifies the event. Since cal.com is sending the invitation of the event with a different UID, if you end up adding this event to your calendar cal.com, it will create a duplicate event in your calendar as well. They need to fix it so that all emails associated with a single event use the same original UID.
3. The event added from cal.com doesn't have a timezone associated with it. Though it mentions the invitees timezone as "America/Chicago" in the notes, the event itself doesn't include a timezone and only specifies the time in UTC. Since the event time is specified in UTC, Fastmail's invitation email will also be sent in UTC.
4. There seems to be no way to stop Cal.com from creating the calendar events at all, and thus no real workaround.

Steps to Reproduce

1. Connect to Fastmail using CalDav integration
2. Create a test booking
3. See issues above.

Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?

1. SCHEDULE-AGENT=CLIENT should be set, so Fastmail knows not to send an invitation. This is the main one.
2. UID should be unique per event.
3. Event time should have a timezone associated with it.
4. An option could be added to make calendar event creation optional (nice-to-have, not essential).

Technical details

None other than Fastmail/CalDAV.

[mtnowl]

FYI @alishaz-polymath

[alishaz-polymath]

Hey guys, thanks for raising the issue. I'll explore this further and keep you guys posted 🙏

[mtnowl]

Just to note, another workaround would be to simply not add the guest emails onto the calendar event. This would prevent Fastmail from having any emails to send invitations to.

[alishaz-polymath]

Just to note, another workaround would be to simply not add the guest emails onto the calendar event. This would prevent Fastmail from having any emails to send invitations to.

This is a workaround, but I don't think it is feasible as a generalized idea. It would definitely make more sense to allow it via the 'SCHEDULE-AGENT=CLIENT' parameter instead, but I need to see how we can do that without risking the same where we don't intend.

This is only going to take some time to explore so we would request and appreciate the patience in the mean time 😅 Thanks for the suggestion 🙏

[Scriptkiddi]

if I understand this correctly this is because of packages/lib/CalendarService.ts:101 where the https://github.com/adamgibbons/ics lib is used. This lib does not support this option yet. I create a pr on the lib side as soon as this is merged I'm going to create one against cal.com with the scheduleAgent: CLIENT for both attendee and organizer.

This would just disable sending Emails from the calendar where the event is beeing created and just cal.com would send the emails. Is that something that you could work with @PeerRich ?

[alishaz-polymath]

cc: @joeauyeung Who is now leading CalDAV at cal.com 🙏

[luckman212]

I think I am seeing this issue as well (cal.com + FastMail CalDAV). Is it the case that one email comes from hello@cal.com and another comes from me@myrealdomain.com?

[manniL]

I can also reproduce this with the NextCloud CalDav integration.

[dasJ]

Opened #11771 for the notification part of this issue since this is very annoying for us

[dasJ]

The timezone issue seems to be a Fastmail thing. cal.com correctly states that its date is in UTC, so I would expect Fastmail to convert this accordingly to your local timezone

[neilj]

cal.com correctly states that its date is in UTC, so I would expect Fastmail to convert this accordingly to your local timezone

We do, in our UI. The report was talking about the (HTML content) in the invitation email that's sent — since we don't know what the recipient's local time zone will be, we use the event's time zone.

[dasJ]

Well the ics package fails here yet again. inputType in formatDate only allows local and if it receives any other value, it treats that as UTC:

    if (inputType === 'local') {
      outDate = new Date(year, month - 1, date, hours, minutes, seconds)
    } else {
      outDate = new Date(Date.UTC(year, month - 1, date, hours, minutes, seconds))
    }

[joeauyeung]

Reading through this issue and I'm hoping that https://github.com/calcom/cal.com/pull/12122 can solve the issue of inconsistent uids.

[Scriptkiddi]

@joeauyeung I might miss read your pr, but how would this issue be fixed by consistent uids?