CalDAV integration with Fastmail is generating duplicate, erroneous invitation emails.
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.
- 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.
- 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.
- 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.
- 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
- Connect to Fastmail using CalDav integration
- Create a test booking
- See issues above.
Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
- SCHEDULE-AGENT=CLIENT should be set, so Fastmail knows not to send an invitation. This is the main one.
- UID should be unique per event.
- Event time should have a timezone associated with it.
- An option could be added to make calendar event creation optional (nice-to-have, not essential).
Technical details
None other than Fastmail/CalDAV.
FYI @alishaz-polymath
Hey guys, thanks for raising the issue. I'll explore this further and keep you guys posted π
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.
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 π
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 ?
cc: @joeauyeung Who is now leading CalDAV at cal.com π
I think I am seeing this issue as well (cal.com + FastMail CalDAV). Is it the case that one email comes from [email protected] and another comes from [email protected]?
I can also reproduce this with the NextCloud CalDav integration.
Opened #11771 for the notification part of this issue since this is very annoying for us
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
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.
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))
}
Reading through this issue and I'm hoping that https://github.com/calcom/cal.com/pull/12122 can solve the issue of inconsistent uids.
@joeauyeung I might miss read your pr, but how would this issue be fixed by consistent uids?
This issue with inconsistent UIDs is annoying and causing duplicate events on Nextcloud as mentioned by @manniL
Looking at the comment from @duburcqa this is still an issue and #16816 is marked as low priority; is there any chance this might get a fix? The suggestion of @duburcqa to enable a setting to disable the organizer e-mail seems sensible. It seems that otherwise CalDAV (and Fastmail) integration should be considered broken.
I'm also experiencing this issue with Fastmail, and as a result I've moved back to SavvyCal.
@neilj is this something which can be fixed in conjunction with Fastmail? Or is it up to Cal.com to fix?
@neilj is this something which can be fixed in conjunction with Fastmail? Or is it up to Cal.com to fix?
No, nothing we can do on our end; we're conforming to the standards. These are bugs in cal.com, so they would have to fix it.
Cal.com 5.0 was just released. Anyone know whether the CalDAV interop issues with Fastmail are still happening?
sadly no one from fastmail was able to reply so far. iβm putting a bounty on this. our core team does not have the capacity/does not know fastmail well enough
/bounty 500
π $500 bounty β’ Cal.com, Inc.
Steps to solve:
-
Submit work: Create a pull request including
/claim #9485in the PR body to claim the bounty - Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts
β Important guidelines:
- To claim a bounty, you need to provide a short demo video of your changes in your pull request
- If anything is unclear, ask for clarification before starting as this will help avoid potential rework
- Low quality AI PRs will not receive review and will be closed
- Do not ask to be assigned unless you've contributed before
Thank you for contributing to calcom/cal.com!
sadly no one from fastmail was able to reply so far. iβm putting a bounty on this. our core team does not have the capacity/does not know fastmail well enough
It seems it's more a general CalDAV problem rather than Fastmail-specific. Specifically @neilj has chimed in and confirmed the fix is on the side of cal.com - not Fastmail.
Thanks for putting a bounty on this!
Is it active issue?
still open
π‘ @Myse1f submitted a pull request that claims the bounty. You can visit your bounty board to reward.
Not able to create test accounts in Fastmail or NextCloud to recreate the issue.
But integrated and tested google calendar with CalDav integration (yeah apart from direct integration with google calendar we can also integrate through CalDav using CalDav Api - https://developers.google.com/workspace/calendar/caldav/v2/guide). No duplication of events or timezone issues with google calendar CalDav integration with cal.com
I am also getting duplicated events with Fastmail. One event from Cal.com and one from my Fastmail address as the organizer.