Hola,
Los eventos recurrentes son eventos individuales, sin embargo, cuando creas uno, no crea temas individuales.
Por lo tanto, si haces clic en uno de esos eventos recurrentes para participar en él, tu participación estará presente en todos los eventos.
¿No debería la creación de un evento recurrente crear eventos/temas individuales con la misma base que el primer evento?
Esto es más bien una solicitud de función. Te entiendo, sería bueno si pudieras elegir un evento particular en una secuencia.
¿Alguna novedad al respecto?
Realmente necesitamos crear un nuevo tema para cada evento, en lugar de que un solo tema de evento controle múltiples eventos visibles en el calendario.
Por ahora, la única solución viable es crear manualmente varios temas nuevos. Por supuesto, esto satura el feed de “Recientes” de una manera muy molesta (lo cual requiere mitigación de alguna forma) y obliga a tener cuidado para no notificar en exceso. Supongo que esto resalta algunos de los desafíos para implementar esta función.
¿Sería aceptable que los eventos secundarios en un tema tuvieran una apariencia diferente, como un contorno, mediante eventBorderColor y eventBackgroundColor?
Simulas la superposición combinando:
| Propiedad | Primario (confirmado) | Secundario / tentativo |
|---|---|---|
| eventBackgroundColor | sólido | diferente / claro |
| eventBorderColor | igual que el relleno | alto contraste |
| estilo de borde | sólido | discontinuo |
| opacidad | 1 | 1 |
Esto crea una jerarquía visual sin necesidad de apilamiento real.
Idea tierna, pero no creo que sea suficiente: cada evento de una serie realmente necesita su propia confirmación de asistencia, información complementaria y discusión.
el RSVP sería reemplazado por la encuesta, por lo que todos los eventos en el tema serían independientes. Los eventos tratarían todos sobre lo mismo: la complejidad de fijar una hora entre varias opciones.
No es realmente una serie ni algo que se pueda lograr en Outlook.
Es el ingrediente especial que aleja a una institución, como la universidad en la que estoy, de las series defensivamente falsas de Outlook y la lleva hacia Discourse.
Vuelvo a esto después de usar el plugin renovado durante los últimos meses; funciona bastante bien ahora que tenemos más opciones de recurrencia, especialmente el día X del mes y la posibilidad de responder a la invitación (RSVP) tanto al evento como a la serie.
Sin embargo, sigue existiendo un problema clave: archivar el contenido del último evento.
El caso de uso es un evento recurrente que tiene bastantes publicaciones/discusiones asociadas. Esto puede incluir archivos adjuntos e imágenes. El ejemplo más obvio es una reunión de trabajo regular.
En este momento, este desorden resultante debe ordenarse manualmente de una u otra forma, ya que lo que hace la recurrencia es simplemente cambiar la fecha del evento y limpiar el RSVP. Las opciones manuales son:
Lamentablemente, ninguna de estas opciones es buena.
Me gustaría que la recurrencia mantuviera el tema del evento actual intacto, pero una vez que esté completado, el plugin crearía un nuevo tema para el próximo evento.
Esto mantendría el flujo agradable y aseguraría automáticamente que se conserve un archivo adecuado del evento pasado, así como proporcionar un tema “limpio” para el nuevo evento.
El precio a pagar (aparte de la complejidad aumentada) sería que el evento activo tendría una nueva URL. Podría ver esto como un problema potencial en algunos casos.
Hola, esto implica que tendrás que esperar a que se cierre el evento actual de la serie de eventos recurrentes antes de poder suscribirte al siguiente evento, ¿verdad?
La mayoría de los plugins de eventos en los que he trabajado en Joomla crearían directamente la serie de eventos, a diferencia de tu idea aquí, que crearía temas/URL individuales por evento, lo cual creo que es el modelo correcto.
Ofrecer la opción de no permitir la suscripción hasta x días antes de los eventos recurrentes también sería práctico.
En cuanto a la parte de archivo, ¿los eventos no suelen residir en su propia subcategoría o ser etiquetables lo suficiente para mantenerlos juntos y tener una acción automatizada sobre ellos?
Sí, pero eso no es diferente a la situación actual, donde puedes responder (RSVP) al evento actual o a toda la serie.
¿Te refieres a una acción para clonar el evento y mover las respuestas, o algo similar? Quizás Workflows podría hacer esto; he estado pensando en investigar al respecto.
En mi experiencia con eventos, confirmar asistencia para toda la serie se usa menos que poder suscribirse a un evento específico más adelante en la serie; aunque ambas opciones son importantes.
Sí, sin embargo no veo ningún workflow en mi instalación que haga eso.
Tal vez en sí mismo sea otra solicitud de función e interesante más allá del alcance del tema de eventos, y podría/debería crear otro tema para esto.
Necesitaríamos una acción de archivo automático desencadenada bajo ciertas condiciones; en este caso, sería cuando la “fecha del evento o la fecha de fin, si existe”, esté en el pasado o el tema esté cerrado desde hace x días, con quizás un retraso opcional antes de que ocurra la acción, para que el tema del evento pueda seguir siendo visible para que la gente comente durante unos días después del evento.
Se ha logrado cierto progreso aquí.
Se ha fusionado un disparador de Fin de evento para Workflows:
Además, Workflows ya cuenta con una acción de Tema que puede Obtener un tema existente y Crear uno nuevo, y existe un nodo de Espera. Por lo tanto, gran parte de la propuesta de rotación podría ser componible como un flujo de trabajo, en lugar de requerir una función de archivado específica para eventos.
Algo como:
Fin de evento → Espera → Tema / Obtener → Tema / Crear
podría crear potencialmente un tema sucesor utilizando los datos de título/cuerpo/categoría del tema anterior, mientras se deja el tema completado intacto como archivo.
Lo que aún debe verificarse es exactamente qué partes del tema antiguo deben copiarse automáticamente: por ejemplo, etiquetas, cargas, estado de recurrencia del evento y si las respuestas deben moverse o simplemente dejarse atrás.
También tengo una PR abierta que introduce una acción de Evento en Workflows:
La PR base agrega Cerrar evento y Abrir evento, y tengo un seguimiento apilado que agrega Establecer asistencia:
La acción está estructurada de manera que se puedan agregar operaciones específicas de eventos adicionales como seguimientos separados donde tenga sentido.
Buen intento, gracias. Las condiciones de cierre pueden ser útiles, pero es posible que no sean totalmente aplicables a la situación original.
Una categoría de eventos puede crecer mucho, sobre todo con eventos recurrentes, y tendría sentido ofrecer una forma de archivar o mover automáticamente cualquier evento de tema cerrado desde hace x días a una categoría de temas pasados o archivarlos.
Pero esta cuestión de archivado depende de la decisión de que los eventos recurrentes se conviertan en temas individuales vinculados al tema principal del evento.
He abierto una PR que implementa esto como un modo de Evento recurrente opcional:
Añade una configuración de sitio discourse_post_event_recurring_topic_mode con dos opciones:
reuse_topic — el comportamiento existente y el predeterminadocreate_next_topic — conserva el tema de la ocurrencia completada y crea un nuevo tema para la siguiente ocurrenciaCon create_next_topic, cuando termina una ocurrencia, el tema completado se conserva con su Evento fijado a esa ocurrencia completada y la recurrencia eliminada. A continuación, se crea un tema sucesor para la siguiente recurrencia, conservando el título, el cuerpo, la categoría, las etiquetas y el autor originales, mientras se avanzan las fechas del Evento.
Las pruebas automatizadas también cubren la semántica de transferencia de RSVP: la asistencia recurrente de going se transfiere al sucesor, mientras que la asistencia única permanece con la ocurrencia completada.
La transferencia también es transaccional, por lo que, si la creación del sucesor falla, la ocurrencia permanece pendiente y puede reintentarse en lugar de quedar a medio completar.
Esto implementa específicamente el modelo de «crear el siguiente tema cuando la ocurrencia actual termina». Aún no genera temas individuales para todas las ocurrencias futuras de antemano, que es el modelo alternativo mencionado anteriormente por @opcourdis.
El comportamiento existente sigue siendo el predeterminado, por lo que esto es opcional para los sitios que desean que el tema del Evento completado actúe como archivo.
Gracias, este modelo ya funciona muy bien para los organizadores, que ahora pueden saber con confianza que no tendrán que recrear el evento cada vez, y también ofrece la tranquilidad de que la gente no se suscribirá con antelación, ya que los organizadores siempre pueden cancelar un evento por ciertas razones.
El modelo de creación anticipada que sugerí también funciona en muchos casos y complementaría tu modelo de sucesor de eventos.
Por cierto, sobre la PR del modo sucesor de eventos:
1° ¿Las personas que se suscriben al nuevo evento siguen sabiendo que el tema/evento forma parte de una serie de eventos recurrentes, como lo hace el evento/tema original?
2° ¿La invitación automática a los invitados originales al evento es una opción de baja/registro (opt out/in)? Digo esto porque un evento futuro no es necesariamente un evento que quieras promocionar siempre a los invitados, ya que ya promocionaste el evento y su serie una vez a través del primer evento.
Sí, en el sentido de que el Evento sucesor conserva la configuración de recurrencia. Por ejemplo, en la prueba de humo de la interfaz gráfica, la ocurrencia original mostraba Cada jueves, y después del cambio de rollover, el Tema sucesor también mostraba Cada jueves con la fecha avanzada a la semana siguiente.
Lo que este PR no añade es una relación de serie entre Temas que vincule el Tema completado y su sucesor. El Tema completado se convierte en la ocurrencia archivada de un solo uso, mientras que el sucesor lleva la recurrencia hacia adelante. Una relación explícita de serie/padre entre esos Temas podría ser una mejora separada si resulta útil.
No transfiere automáticamente a cada invitado/asistente al nuevo Evento.
El sucesor solo hereda a las personas que estaban asistiendo con la RSVP de recurrencia/serie habilitada. Alguien que respondió asistiendo solo a la ocurrencia individual permanece en el Tema completado y no se añade al sucesor.
Por lo tanto, en la actualidad, la opción existente de responder a la serie actúa efectivamente como el opt-in para ser transferido a los Eventos sucesores futuros, en lugar de que exista otra configuración del sitio que lo controle.