cal.com
cal.com copied to clipboard
Get availability from ics-URL
Is your proposal related to a problem?
I would like to be able to share my calendar availability automatically without having to grant full CalDav access.
Describe the solution you'd like
Many calendar providers offer a URL with free/busy information only, i.e., no details of calendar events. That URL returns an ics-file with events, except that the event details are hidden.
Example: Fastmail.com

Being able to add URL to an .ics/ical file as an Integration for availability. This would be read-only, i.e., confirmed events cannot be scheduled with this integration.
Ideally, it should be possible to add several such URLs (i.e., multiple calendars, e.g., one for private, one for work, etc.)
Describe alternatives you've considered
CalDav, but this requires me to share all details of the calendar.
Additional context
Such an approach would also allow integration with some other calendar platforms that are not yet supported but which do support creating a secret URL for an ics-file.
Thanks for the suggesition. Our team will have a look into this
semi-duplicate of #3167
I'm not sure I understand the above description very well, but isn't it an exact duplicate of #3167?
@mountainsandcode Please can you confirm that you are asking for the ability for cal.com to import availability from ICS feed URLs, rather than for cal.com to export an ICS feed? In other words, when you say
I would like to be able to share my calendar availability
do you mean sharing availability of another calendar with cal.com, or availability of cal.com with another calendar?
I think both are really important, but they are independent features, so they should be tracked in separate GitHub issues.
I said semi-duplicate because AFAIU this issue, it refers to the ability to import iCalendar's published VFREEBUSY info specifically (see last example https://icalendar.org/iCalendar-RFC-5545/3-6-4-free-busy-component.html ), whereas #3167 refers to importing availability just by looking at existing events (not VFREEBUSY) in an iCalendar.
If I'm right, I think these two can be tracked in a single because a feature that imports availability info from an ICS file/feel should ideally support both, i.e., take into account VFREEBUSY as well as scheduled events plus their time transparency ("show as free"/"show as busy", https://icalendar.org/iCalendar-RFC-5545/3-8-2-7-time-transparency.html) .
@aspiers Indeed there is considerable overlap, though #3167 was raised later so one could say that one is the duplicate ;) In any case, doesn't matter which issue we are tracking this under :) Happy to close this one as the other one is perhaps more active/ documented.
I would fully agree with @real-or-random's suggestion - I think the behaviour should be the same regardless of whether we are considering VEVENTs or VFREEBUSY.
Thanks for the clarifications! And I also agree with @real-or-random and @mountainsandcode that imports of VFREEBUSY and "normal" ICS files with VEVENTs can both be dealt with by the same feature implementation.
Please note that I have proposed #3810 as a request for the "opposite" feature, i.e. cal.com being able to export an aggregated ICS feed (which could be a collection of either VFREEBUSY or VEVENT) to other systems, in contrast to this and #3167 which are both about cal.com importing an ICS feed. I see great value in both features, even though they are pretty much exact opposites of each other.
I recommend to consider some of the options NC Appointments offers as well :) https://github.com/SergeyMosin/Appointments
I recommend to consider some of the options NC Appointments offers as well :) https://github.com/SergeyMosin/Appointments
Thank you @xeruf for the suggestion. Just to confirm: is the Nextcloud Appointments app you linked to capable of getting availability from an external ICS URL that's not from that Nextcloud instance? For example, can it subscribe to ICS URLs from Google or Outlook?
I don't think so, but it should not make much of a difference in terms of implementation - and weekly template and slots from calendar "FREE" events are also good considerations.
given that this capability would unlock automatic integration with a vast array of calendar services without needing to do service-specific integrations (for instance, Proton calendars, and any other calendar host), I think it makes sense to drop the low-priority label on this ticket.
Closing in favor of issue #3167