Undefined ICS file name

[dax (Daniela)]

Overview

When clicking “Add to calendar” in the event preview modal (the one that appears after clicking on the event’s date), the downloaded .ics file is named undefined.ics and the event title inside the calendar file is also set to SUMMARY:undefined. However, downloading the calendar via the “Add to calendar” option from the event’s 3-dot menu works as expected, using the event’s title for both the filename and the calendar summary.

Steps to reproduce

1. Create or open a topic with an event

2. Click on the event date shown in the post to expand the preview modal:
   

   

3. In the modal, click on Add to calendar

4. Save the generated .ics file.

5. Optionally, compare by clicking on the event’s 3-dot menu and using Add to calendar from there

Expected results

• The downloaded .ics file should be named after the event’s title
• The calendar file content should have a correct SUMMARY: with the event title

Observed results

• The downloaded file is named undefined.ics
• The event title in the calendar file is SUMMARY:undefined
• (When downloaded from the 3-dot menu, both filename and summary are correct.)

Additional context

• Example of malformed ICS content:

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//Discourse//EN
  BEGIN:VEVENT
  UID:1762794000000_1762801200000
  DTSTAMP:20251105T173754Z
  DTSTART:20251110T170000Z
  DTEND:20251110T190000Z
  SUMMARY:undefined
  END:VEVENT
  END:VCALENDAR
  

Tested on Meta and several other Discourse sites, same result.

[sam (Sam Saffron)]

This is a tricky one Dax which is a side effect of our pipeline.

We generate the bbcode for the dates here:

plugins/discourse-calendar/assets/javascripts/discourse/components/discourse-post-event/dates.gjs

And cook it here:

plugins/discourse-calendar/assets/javascripts/discourse/components/discourse-post-event/dates.gjs

So in the context of the cooked chunk of html the “download ics” is not aware of the actual post it is on (or event)

We also have a different pipeline for ics generation at:

frontend/discourse/app/lib/download-calendar.js

So we need to decide from an engineering perspective if:

1. We teach the “date cooking” how to re-route ics generation to Discourse Calendar.

OR

2. We provide enough context to Discourse Local Dates, so it can independently generate the ics and keep the code fractured.

I am not sure what the correct thing is to do here, but I have prioritized it so the team can triage and sort it out.

[Ric (Ric Harvey)]

Hi both to add some context, if you click on the three dots on an event there is a Add to Calendar option and this does work. I don’t know if that can help you look into this but seems it’s been solved elsewhere in the code.

edit: Of course @dax said this but I didn’t read properly!

[sam (Sam Saffron)]

There is A LOT here:

https://github.com/discourse/discourse/pull/35886

It is Friday (at least somewhere ;p ) so I will wait till Monday to merge.

This change is incredibly extensive and should give us significantly better ICS support.

• Unifies the pipeline for ICS generation - we only use one mechanism for both add to calendar and clicking on dates
• Corrects many small bits of nuance in the ics format
  • We pass on RRULE so if you grab a recurring event
  • Proper CRLF line breaks and general adherence to ICS format
  • Timezone support so when you grab an ICS for an event it will signal the correct timezone vs be a UTC event - this means recurrence will work.
• Expands the local dates format to support an optionally encoded ics

An open question I have is yes, rrule or no, rrule.

If you click here:

Do we intend to add the recurring event? Or just a single instance of the event?

Similarly, what about here:

@lindsey I am on the fence here, I can see this argued either way.

1. I clicked on a recurring event and wanted to add the recurrence to my calendar

OR

2. I clicked on an INSTANCE of a recurrence and only want to add it.

I implemented (1) cause I tend to feel it is more correct, but I am open to changing it to 2 if you prefer.

[lindsey (Lindsey Fogle)]

@sam

1. I clicked on a recurring event and wanted to add the recurrence to my calendar

@sam

I implemented (1) cause I tend to feel it is more correct, but I am open to changing it to 2 if you prefer.

I can understand the argument in either direction but I also prefer 1. I think it’s both more correct, and easier to “fix” if it wasn’t what the user wanted, because most calendar softwares make it quite easy to delete extra events with a single action (such as Google Calendar):

So the hassle of:

• I didn’t want to RSVP to all events, so I need to remove the extra ones

Is much lower than the hassle of:

• I did want to RSVP to all events, so I need to come back here each week and make sure to keep adding them to my calendar

[sam (Sam Saffron)]

Cool I went ahead and kept the RSVP to all.

It was merged today