Hemos añadido una nueva pestaña Calendario a las preferencias del usuario que te permite suscribirte a las fuentes de Discourse en aplicaciones de calendario externas como Google Calendar, Apple Calendar y Microsoft Outlook.
Mis Eventos — eventos a los que vas a asistir o que te interesan
Para desarrolladores de plugins
Los plugins pueden registrar fuentes ICS adicionales usando la nueva API register_calendar_subscription_feed. Las fuentes registradas de esta manera aparecen automáticamente en la pestaña de preferencias de Calendario cuando el plugin está habilitado.
Seguridad
Las URLs de suscripción utilizan claves de API de usuario limitadas restringidas al acceso de solo lectura en formato ICS. Las claves tienen límites de velocidad y las URLs se muestran una sola vez en el momento de la generación; los usuarios pueden regenerarlas en cualquier momento, lo que revoca las URLs antiguas.
Gracias @Falco, pero ¿cómo se eliminan las opciones corporativas? Me parece ofensivo para mi comunidad tener que ver publicidad de servicios propietarios.
¡Muchas gracias por esta implementación; esto aumentará la usabilidad del complemento de calendario/eventos para muchas comunidades!
Tengo la misma objeción que @hellekin: dentro de Discourse, estamos en un entorno de código abierto. En nuestra comunidad, nadie utiliza Google Calendar ni Microsoft. Si los usuarios necesitan un enlace para estos servicios propietarios, deberían decidirlo ellos mismos, no la aplicación. Por lo tanto, preferiría seleccionar el tipo de servicio de calendario externo durante el paso de creación de las URL de suscripción (por ejemplo, con algunas casillas de verificación), no más tarde.
Tenemos múltiples comunidades en nuestra instancia de Discourse. Están separadas por permisos de grupo y algunos usuarios son miembros de más de una comunidad. Sería conveniente filtrar la URL de “Discourse Calendar - All Events” para que solo muestre las entradas del calendario de una comunidad en particular. URL de ejemplo
Con esta mejora sería posible compartir los eventos de Discourse de una comunidad en particular (!) en su propio sitio web, por ejemplo, con el complemento de WordPress “ICS calendar”.
Otra pequeña mejora propuesta: si deseas suscribir los eventos de Discourse en dos clientes diferentes (por ejemplo, Thunderbird en dos dispositivos), necesitas copiar la URL dos veces. Pero actualmente la URL solo se muestra una vez. Si agregas un segundo cliente, tienes que regenerar las URL y pierdes las primeras.
[quote=“Falco, post:7, topic:398902”]Solo necesitas copiar una vez y luego pegar en los dos clientes que necesites.
Y si olvidas un cliente, puedes regenerar con un solo clic.
[/quote]
Entiendo, pero mi punto es la regeneración necesaria después de que se muestren las URL por primera vez.
Si utilizo el enlace del calendario en dos dispositivos diferentes, es probable que no estén disponibles para configuración al mismo tiempo. Accedería a mi perfil de Discourse desde el primer dispositivo y más tarde de nuevo desde el segundo dispositivo. Sería mejor mostrar la URL antigua de nuevo y solo invalidarla mediante solicitud explícita.
Si soy miembro de dos comunidades diferentes (y sus grupos de permisos), la URL “https://discourse.example.com/discourse-post-event/events.ics“ muestra los eventos de ambas comunidades. Eso es correcto hasta ahora. Pero ambas comunidades pueden tener su propio sitio web. Si quiero compartir los eventos de Discourse en sus sitios web, solo querría ver los eventos de la “comunidad A” pero no de la “comunidad B”. Y viceversa.
Si hablas de los servicios de calendario de otros proveedores, el principio es el mismo: 1 o 2 veces al día. En su momento, no encontré ninguna solución para aumentar la frecuencia de sincronización. Después, me di cuenta de que es totalmente normal, dado el número de calendarios que hay que sincronizar en todo el mundo Creo que lo limita para no saturar sus servidores.
Contexto: nuestra instancia de Discourse es compartida entre varios grupos de usuarios/comunidades que tienen sus propios grupos de permisos. Tenemos una categoría principal para cada uno de estos grupos. Esta categoría es visible públicamente y su contenido se federado en el Fediverse (Discourse ActivityPub). También muestra un calendario público. Ejemplo (https://forum.netzwissen.de/c/meshcore-str/84):
El calendario muestra eventos de publicaciones en la categoría principal y también de subcategorías. Las publicaciones de eventos en las subcategorías (que solo son visibles para usuarios “con sesión iniciada” del grupo de permisos de la comunidad) no aparecen en el calendario principal para usuarios anónimos (sin iniciar sesión). Perfecto, esto es el comportamiento esperado.
Veo dos requisitos que harían que el enlace del calendario ICS esté “completo en cuanto a funcionalidad”. Usamos el nuevo enlace del calendario ICS para compartir eventos creados en Discourse en los sitios web públicos de las comunidades (CMS: WordPress).
Los eventos mostrados en el archivo ICS deberían ser “filtrables” por comunidad/grupo de permisos. Sintaxis propuesta:
El archivo ICS solo debería mostrar eventos con estado “público”. Los eventos con estado “privado” o “independiente” generalmente no deberían publicarse en el archivo ICS. Nota: aún no he probado si esto ya está implementado…
Lamentablemente, aunque el complemento Calendario está habilitado (y lo hemos estado usando con regularidad), al generar las URLs para mi usuario solo se crea la suscripción a Favoritos. ¿Alguna idea sobre por qué podría ocurrir esto?
También estoy de acuerdo con @Thomas_Rother en que las URLs de suscripción deberían mostrarse hasta que se revocen o regeneren. Los dispositivos y las aplicaciones cambian con el tiempo, y tener que volver a suscribirse en todos los dispositivos solo porque se quiera añadir uno más es tedioso y parece innecesario. Quizás podría ser una opción de configuración del complemento, dependiendo de la sensibilidad de los datos de los eventos.
¿Podría ser un problema con las instalaciones que usaban el plugin por separado antes? También intenté desactivar y reactivar el plugin, pero no solucionó el problema.
¡Vine aquí buscando exactamente esta función, así que me alegra mucho que se haya implementado!
Comparto la opinión de @hellekin y @Thomas_Rother sobre los enlaces corporativos. Sería genial si pudieran hacerse opcionales. Muchas personas usan Discourse porque creen en la soberanía digital, por lo que mostrar estos logotipos no es apropiado.
Lo más importante es la visibilidad de la función. Está oculta en las preferencias del usuario, pero sería muy bien recibida directamente en la navegación de la interfaz del calendario. Hacer clic en “Próximos eventos” y luego ver un enlace para suscribirse sería oro.
Creo que lo limita para no saturar sus servidores.
