Hola,
Sería bueno tener el comportamiento que se eliminó en #231.
Específicamente, poder apuntar un cliente iCal a events.ics o equivalente para obtener todos los eventos del sitio.
Además, faltan los campos DESCRIPTION, URL y ORGANIZER en el reemplazo de download-calendar.js. Los dos primeros son más importantes para mí.
Sería aún mejor incorporar #169 para agregar exportaciones de eventos “por tema”, pero eso es adicional.
También estaría muy contento si pudiera suscribirme a eventos de mi calendario.
Reflejando /upcoming-events, me encantaría ver un /upcoming-events.ics.
Pero sí, tener una forma de obtenerlo para una sola categoría (¿o incluso una sola etiqueta?) probablemente también sería una gran adición.
¿Quizás /upcoming-events.ics?category=12 para filtrar por ID de categoría?
+1 en feed ics completo y filtrado por tema.
Sé que esto es difícil debido a la privacidad. La ruta habitual es que se genera un feed hash aleatorio que representa un feed por usuario.
umm, ¿qué… al menos es una URL pública con el calendario que usemos…
También quiero expresar mi apoyo a esta función. Ya he votado sobre este tema.
Recuperar una exportación de ICS completa del sitio o por usuario sería extremadamente valioso para el flujo de trabajo de nuestra comunidad. ¿Hay alguna actualización sobre la reconsideración de lo que se eliminó en PR #231?
Si existen preocupaciones de privacidad o implementación, quizás se podría considerar un feed ICS privado por usuario como solución.
¡Gracias por considerarlo!
No creo que haya preocupaciones de privacidad, ya que el endpoint .json ya existe de todos modos, esto es solo un tipo de formato diferente.
@cvx / @j.jaffeux ¿opiniones sobre traer de vuelta .ics a la ruta del índice de eventos (eliminado en: DEV: Remove old ics code by CvX · Pull Request #231 · discourse/discourse-calendar · GitHub)? Me parece una victoria fácil.
Ya hacemos:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
Y podemos tener un MAX_RESULTS (ordenado por el más reciente) para asegurar que esto y el .json no se vuelvan demasiado grandes.
He vuelto a añadir la capacidad de exportación de ics a través de GET /discourse-post-event/events.ics (según DEV: add ical format response for discourse-post-events index route by tyb-talks · Pull Request #35143 · discourse/discourse · GitHub). Tenga en cuenta que este endpoint tiene un límite estricto de 200 eventos. Si su sitio tiene más eventos que ese y desea realizar una exportación completa, puede iterar utilizando los parámetros de consulta before y after, que aceptan cadenas de fecha. Añadiremos la lista completa de parámetros aceptables para este endpoint a la documentación de la API en su debido momento.
Gracias por fusionar PR #35143 — me alegra ver que la exportación .ics ha vuelto oficialmente.
Una cosa que quería comprobar: ¿existe alguna posibilidad (o plan futuro) de autenticar este feed con un token de usuario o una clave API, de forma similar a como Discourse maneja los feeds privados de RSS/Atom (/topics/feed.rss?token=…)?
Ahora mismo /discourse-post-event/events.ics parece funcionar solo para eventos públicos, lo que significa que Outlook/Google Calendar no pueden suscribirse a categorías privadas.
Incluso un enfoque ligero basado en tokens (por usuario o por sitio, de solo lectura) haría posible exponer de forma segura eventos privados en clientes de calendario sin tener que reenviar el feed a través de un script externo.
¿Es algo que se podría añadir, o ya es posible a través de un parámetro existente que podría haberme perdido?
Esto parece una solicitud de función separada. Creo que es técnicamente factible con una clave API, así que supongo que la pregunta es cómo facilitarías esto.
Voy a cerrar esto y permitirte abrir un nuevo elemento al respecto.