The community discussed enhancing the Discourse calendar plugin with iCal export and CalDAV support to improve integration with external systems. Thomas_Rother initiated the thread by linking to an older request, arguing that while iCal export is file-based, CalDAV would require a service API but is essential for syncing with open systems like Radicale. He suggested Discourse act as a CalDAV client for read-only access first, then write permissions. opcourdis agreed CalDAV is a basic requirement and asked about fundraising, though later noted that a one-way Webcal feed would be faster to implement than a full two-way sync server. nathank and angus pointed to the Events Plugin as a solution that imports from iCalendar-compatible sources including CalDAV, though Thomas_Rother initially clarified that a client implementation and UI were still missing. sam announced that iCal downloads were completed, but nathank corrected that this feature already existed and highlighted a bug where the Location field is not passed through in .ics files. sam acknowledged the bug. Ethsim2 noted that the Events Plugin’s subscription program had ended, potentially limiting its utility, but sam mentioned recent work to re-add full iCal export. Finally, Falco confirmed that calendar subscription URLs for external apps have been implemented, addressing the core request for external calendar integration.
As this request from our community appeared again, I would like to link this older feature request which was not located in the correct category:
Calendar: export to caldav/carddav](Calendar: export to caldav/carddav)
While ical export is file based, caldav would require a dav service with appropriate API calls. The ical export option would be easier, I assume …
caldav subscription is a basic of any event management extension, where could we start a fundraising for this feature?
Absolutely true.
From my point of view the current implementation of calendar functionality is only useful for use cases, where all time management is prepared inside of Discourse and/or with some proprietary solutions like the Gmail calendar. This makes it somehow “isolated” as there is no integration with other open systems.
In many cases people use external calendar solutions which are independent from a specific provider (e.g. Radicale caldav/carddav server in python). They simply want to display the calendar inside of the forum (“read only”) and sync with external changes automatically.
If discourse could act as a caldav client (like thunderbird on the desktop and DAVx⁵ on android), this would be a big step. At first it could be “read only”, second step would be the implementation of write permissions to external caldav calendars. This should be linked to the user profile which is a different approach as the current calendar plugin.
Caldav is more practical indeed for a community and is also a lot of work as as you mention it, it needs to act as a server for a 2 way sync.
On the other hand a Webcal feed is just a one way collection and broadcast of data which would be way easier and faster to implement.
I understand the need for caldav but it may delay the implementation of the more quickly feasible feature that webcal is.
You might like to take a look at @angus’s Events Plugin 📅, which basically does what I believe you are looking for.
It has its own UI for events, or you can use the official Discourse #calendar-and-event plugin and UI, and it will just do the backend stuff.
I dont think so. We dont need CalDav calendar server functionality in Discourse. The Radicale Server I mentioned earlier is a small Python based Caldav/CardDav server which already solves all server-side requirements, for both CalDAV and CardDAV. The only thing missing on the Discourse side is a client implementation and a UI to display and edit the content. @angus Events plugin does not fill this gap yet.
The Events Plugin lets you import events from any iCalendar (RFC 5545) compatible source, which includes CalDav.
ok, then I may have missed something. Thanks for the info!
Any chance to have ical url subscriptions in the future like it was the case with Pavilion plugin?
Errr - they were already a feature when the OP was posted here. I don’t think that is what they were looking for.
Please also note that the Location field (which is kind of critical for Events via .ics) isn’t currently being passed through:
That is a bug, let’s make sure there is a dedicated bug topic for it
I am having trouble parsing this, what does this mean in practice?
both these posts came before Angus dropped the subscription program for this plugin, so the events plugin won’t solve anything now
I think @kelv added some of this back per:
https://github.com/discourse/discourse/pull/35143
What is the scope of this request?
Done in
