Problem/Motivation
My university uses Drupal 10 for their website. They have an "add to calendar" button on each event's page that downloads an ICS file. I noticed that both Thunderbird and Google Calendar did not like how this file was formatted.
I identified multiple issues with it, some of them were fixed (i believe adding the "Z" to datetime values in version 4.0.7, commit 820c86d8115873df01f3999121443fc38d8c79ab was one of the fixes, so consider that a lower bound on what version is in use)
However I still believe there is an issue regarding the description field. It seems like the event description is being provided to date_cal as text containing multiple lines and these are being inserted into the ics in a way that isnt quite following the specification (link to the relevant section of the technical documentation for what im talking about: https://www.rfc-editor.org/rfc/rfc5545#section-3.1).
Essentially, if the description is more than a single line long, the second line, and any subsequent lines should be inserted into the ICS file beginning with a single space (if the line was broken in the middle of a word) or potentially two spaces (if the description contains a space at the location that the description was split at).
Steps to reproduce
Unfortunately I don't have admin permissions so i cannot test these steps
1. create an event with a description that contains at least one newline
2. try to export it to ICS
3. try to import the ICS into a calendar program
Expected result: ICS file correctly handles the newline in the description
Likely actual result: The file doesnt contain the spaces according to the spec and fails to import
Proposed resolution
I believe it is reasonable to include some additional handling of descriptions to this plugin (it seems as though theres already some basic HTML sanitization happening) to properly handle multi-line descriptions when adding them to a generated ICS file
I'm willing to help with this but am a new contributor so I may need some guidance on how to set up an environment to be able to test this (either with unit testing or inside an actual drupal instance)
Remaining tasks
User interface changes
None needed
API changes
None needed
Data model changes
None needed