el archivo .ics descargado se nombra undefined.ics y el título del evento dentro del archivo del calendario también se establece en SUMMARY:undefined. Sin embargo, descargar el calendario a través de la opción “Añadir al calendario” desde el menú de 3 puntos del evento funciona como se esperaba, utilizando el título del evento tanto para el nombre del archivo como para el resumen del calendario.
Pasos para reproducir
Crear o abrir un tema con un evento
Hacer clic en la fecha del evento que se muestra en la publicación para expandir la ventana modal de vista previa
En la ventana modal, hacer clic en Añadir al calendario
Guardar el archivo .ics generado.
Opcionalmente, comparar haciendo clic en el menú de 3 puntos del evento y utilizando “Añadir al calendario” desde allí
Resultados esperados
El archivo .ics descargado debe nombrarse según el título del evento
El contenido del archivo del calendario debe tener un SUMMARY: correcto con el título del evento
Resultados observados
El archivo descargado se nombra undefined.ics
El título del evento en el archivo del calendario es SUMMARY:undefined
(Cuando se descarga desde el menú de 3 puntos, tanto el nombre del archivo como el resumen son correctos).
Este es un caso complicado, Dax, que es un efecto secundario de nuestro pipeline.
Generamos el bbcode para las fechas aquí:
Y lo procesamos aquí:
Por lo tanto, en el contexto del fragmento de HTML procesado, la opción “descargar ics” no tiene conocimiento de la publicación en la que se encuentra (o del evento).
También tenemos un pipeline diferente para la generación de ics en:
Así que necesitamos decidir desde una perspectiva de ingeniería si:
Enseñamos al “procesamiento de fechas” cómo redirigir la generación de ics a Discourse Calendar.
O
Proporcionamos suficiente contexto a Discourse Local Dates para que pueda generar el ics de forma independiente y mantener el código fragmentado.
No estoy seguro de cuál es la acción correcta a tomar aquí, pero la he priorizado para que el equipo pueda clasificarla y resolverla.
Hola a ambos, para añadir algo de contexto, si haces clic en los tres puntos de un evento, hay una opción de Añadir al calendario y esta sí funciona. No sé si eso puede ayudarles a investigar esto, pero parece que ya se ha resuelto en otra parte del código.
Es viernes (al menos en algún lugar ;p ) así que esperaré hasta el lunes para fusionar.
Este cambio es increíblemente extenso y debería darnos un soporte ICS significativamente mejor.
Unifica el pipeline para la generación de ICS: solo usamos un mecanismo tanto para agregar al calendario como para hacer clic en las fechas.
Corrige muchos pequeños matices en el formato ics
Pasamos RRULE, así que si tomas un evento recurrente
Saltos de línea CRLF adecuados y cumplimiento general del formato ICS
Soporte de zona horaria, de modo que cuando tomes un ICS para un evento, señalará la zona horaria correcta en lugar de ser un evento UTC; esto significa que la recurrencia funcionará.
Expande el formato de fechas locales para admitir un ics codificado opcionalmente.
Una pregunta abierta que tengo es sí, rrule o no, rrule.
Puedo entender el argumento en cualquier dirección, pero yo también prefiero el 1. Creo que es más correcto y más fácil de “arreglar” si no era lo que el usuario quería, porque la mayoría de los programas de calendario facilitan la eliminación de eventos adicionales con una sola acción (como Google Calendar):
Resumen
Pasos para reproducir
Resultados esperados
Resultados observados
Contexto adicional
