The discussion revolves around re-adding a full ICS export feature for events in Discourse, which was previously removed. Users mjsir911, Julien_Palard, bmann, Robert_McCurdy, and Ethsim2 advocate for restoring the ability to access all events via an ICS feed, either site-wide or filtered by topic. Ethsim2 emphasizes the feature’s value for community workflows. sam suggests that since the .json endpoint already exists, the ICS export is a matter of formatting, not privacy. kelv confirms that the /discourse-post-event/events.ics endpoint has been re-added in PR #35143, though it currently limits results to 200 events. Ethsim2 then asks if authentication via a user token or API key could be added to allow private access, similar to other Discourse feeds. sam responds that while it’s possible, it would require a separate feature request.
Hi,
It would be nice to have the behavior that was removed in #231.
Specifically, being able to point an ical client towards events.ics or equivalent to get all events on the site.
Additionally, the DESCRIPTION, URL & ORGANIZER fields are missing from the download-calendar.js replacement. The first two are more important to me.
It would be even nicer to pull in #169 to add “per-topic” event exports, but that’s extra
I also would be very happy if I could subscribe to events from my calendar.
Mirroring /upcoming-events I’d love to see a /upcoming-events.ics.
But yeah, having a way to get it for a single category (or even a single tag?) would probably be a great addition too.
Maybe /upcoming-events.ics?category=12 to filter by category id?
+1 on full ics feed and filtered by topic.
I know this is hard because of privacy. The usual path is that a random hash feed representing a per user feed is generated.
umm what … it’s public URL at least with whatever calendar we use …
I just want to add my support for this feature as well. I have already voted on this topic.
Bringing back a full-site or per-user ICS export would be extremely valuable for our community’s workflow. Is there any update on reconsidering what was removed in PR #231?
If there are privacy or implementation concerns, perhaps a private, per-user ICS feed could be considered as a solution.
Thanks for considering this!
I don’t think there are any privacy concerns, cause the .json endpoint is already there anyway, this is just a different type of formatting.
@cvx / @j.jaffeux thoughts on bringing back .ics to the event index route (removed in: DEV: Remove old ics code by cvx · Pull Request #231 · discourse/discourse-calendar · GitHub) ? Seems like an easy win to me.
We already do:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
And can have a MAX_RESULTS (order by most recent) to ensure this and the .json don’t get too big.
I’ve added back the capability for ics export via GET /discourse-post-event/events.ics (as of DEV: add ical format response for discourse-post-events index route by tyb-talks · Pull Request #35143 · discourse/discourse · GitHub ) . Do note that this endpoint has a hard limit of 200 events. If your site has more events than that and you want to do a full export, you may iterate through by using the before and after query parameters which accept date strings. We’ll be adding the full list of acceptable parameters for this endpoint to the API docs in due course.
Thanks for merging PR #35143 — great to see the .ics export officially back.
One thing I wanted to check: is there any possibility (or future plan) to authenticate this feed with a user token or API key, similar to how Discourse handles private RSS/Atom feeds (/topics/feed.rss?token=…)?
Right now /discourse-post-event/events.ics seems to work only for public events, which means Outlook / Google Calendar can’t subscribe to private categories.
Even a lightweight token-based approach (per-user or per-site, read-only) would make it possible to securely expose private events in calendar clients without having to proxy the feed through an external script.
Is that something that could be added, or is it already possible through an existing parameter I might have missed?
This feels like a separate feature request. I think it is technically doable with an API key, so I guess the question is how would you easily swing this.
going to close this off and let you open a new item about this.