Bonjour,
Les événements récurrents sont des événements individuels, cependant lorsque vous en créez un, cela ne crée pas de sujets individuels.
Donc, si vous cliquez sur l’un de ces événements récurrents pour y participer, votre participation est présente sur tous les événements.
La création d’un événement récurrent ne devrait-elle pas créer des événements/sujets individuels avec la même base que le premier événement ?
C’est tout à fait une demande de fonctionnalité. Je vous entends, ce serait bien si vous pouviez choisir un événement particulier dans une séquence.
Quelques avancées de ce côté ?
Nous avons vraiment besoin qu’un nouveau sujet soit créé pour chaque événement, plutôt qu’un seul sujet d’événement qui contrôlerait un grand nombre d’événements visibles dans le calendrier.
Pour l’instant, la seule solution de contournement viable consiste à créer manuellement plusieurs nouveaux sujets. Cela remplit évidemment le flux « Récent » de manière très agaçante (ce qu’il faut atténuer d’une manière ou d’une autre), tout en exigeant que vous fassiez attention à ne pas trop notifier. Je suppose que cela met en lumière certains des défis liés à la concrétisation de cette fonctionnalité.
Serait-il acceptable que les événements secondaires d’un topic aient une apparence différente, par exemple un contour, via eventBorderColor et eventBackgroundColor ?
Vous simulez la superposition en combinant :
| Propriété | Primaire (confirmé) | Secondaire / provisoire |
|---|---|---|
| eventBackgroundColor | plein | différent / clair |
| eventBorderColor | identique au remplissage | fort contraste |
| style de bordure | plein | pointillé |
| opacité | 1 | 1 |
Cela crée une hiérarchie visuelle sans avoir besoin d’une superposition réelle.
Idée mignonne, mais je ne pense pas que cela aille tout à fait assez loin : chaque événement d’une série nécessite vraiment son propre RSVP, des informations complémentaires et un espace de discussion.
Le RSVP serait remplacé par le sondage, de sorte que tous les événements du sujet seraient autonomes. Tous les événements porteraient sur la même chose : la complexité de la fixation d’un horaire parmi plusieurs options.
Ce n’est vraiment pas une série ni quelque chose qui peut être réalisé dans Outlook.
C’est la touche spéciale qui incite une institution, comme l’université où je me trouve, à abandonner les séries Outlook défensives et erronées pour se tourner vers Discourse.
Je reviens sur ce sujet après avoir utilisé la version améliorée du plugin au cours des derniers mois ; il fonctionne plutôt bien maintenant que nous avons plus d’options de récurrence - en particulier le Xème jour du mois, et la possibilité de répondre par RSVP soit à l’événement, soit à la série.
Cependant, un problème majeur subsiste : l’archivage du contenu du dernier événement.
Le cas d’utilisation est un événement récurrent qui a pas mal de publications / discussions associées. Cela peut inclure des fichiers joints et des images. L’exemple le plus évident est une réunion de travail régulière.
Pour l’instant, ce désordre résultant doit être trié manuellement d’une manière ou d’une autre, car ce que fait la récurrence, c’est simplement changer la date de l’événement et effacer les RSVP. Les options manuelles sont :
Malheureusement, aucune de ces options n’est vraiment idéale.
Je voudrais que la récurrence conserve le sujet de l’événement actuel intact, mais une fois celui-ci terminé, le plugin créerait un nouveau Sujet pour le prochain événement.
Cela maintiendrait le bel enchaînement, et garantirait automatiquement qu’une archive appropriée de l’événement passé est conservée - tout en offrant un Sujet “propre” pour le nouvel événement.
Le prix à payer (outre une complexité accrue) serait que l’événement actif aurait une nouvelle URL. Je peux voir que cela pourrait potentiellement poser problème dans certains cas.
Bonjour, cela implique-t-il qu’il faudra attendre que l’événement actuel de la série d’événements récurrents soit clôturé avant de pouvoir s’abonner à l’événement suivant ?
La plupart des plugins d’événements sur lesquels j’ai travaillé sous Joomla créent directement la série d’événements, à la manière dont votre idée ici créerait des sujets/URL individuels pour chaque événement, ce qui me semble être le bon modèle.
Offrir l’option d’interdire l’abonnement jusqu’à x jours avant les événements récurrents serait également pratique.
Pour la partie archivage, les événements ne sont-ils pas principalement regroupés dans leur propre sous-catégorie ou suffisamment balisables pour les maintenir ensemble et y appliquer une action automatisée ?
Oui, mais cela ne diffère pas de la situation actuelle, où l’on peut répondre à l’événement en cours ou à l’ensemble de la série.
Tu veux dire une action pour cloner l’événement et déplacer les réponses, ou quelque chose de similaire ? Peut-être que les Workflows pourraient le faire ; j’ai l’intention d’y jeter un œil.
Selon mon expérience avec les événements, confirmer sa présence pour toute la série est moins utilisé que la possibilité de s’abonner à un événement précis plus tard dans la série ; les deux options sont toutefois importantes.
Oui, cependant je ne vois aucun workflow qui le fasse dans mon installation.
C’est peut-être en soi une autre demande de fonctionnalité, intéressante au-delà du cadre du sujet des événements, et je pourrais/je devrais créer un autre sujet à ce sujet.
Nous aurions besoin d’une action d’archivage automatique déclenchée par certaines conditions ; ici, il s’agirait de « la date de l’événement ou la date de fin, si elle existe » est passée, ou le sujet est fermé depuis x jours, avec peut-être un délai sélectionnable avant que l’action ne se produise, afin que le sujet de l’événement reste visible pour que les gens puissent commenter pendant quelques jours après l’événement.
Des progrès ont été réalisés ici.
Un déclencheur Event ended (Fin d’événement) pour les Workflows a désormais été fusionné :
De plus, les Workflows disposent déjà d’une action Topic (Sujet) qui permet de Get (Récupérer) un sujet existant et de Create (Créer) un nouveau, ainsi que d’un nœud Wait (Attente). Ainsi, une grande partie de la bascule proposée pourrait déjà être composée en tant que workflow, sans nécessiter une fonctionnalité d’archivage dédiée à un événement spécifique.
Quelque chose comme :
Event ended → Wait → Topic / Get → Topic / Create
pourrait potentiellement créer un sujet successeur en utilisant le titre, le corps et les données de catégorie de l’ancien sujet, tout en laissant le sujet terminé intact en tant qu’archive.
Il reste à vérifier exactement quelles parties de l’ancien sujet doivent être copiées automatiquement — par exemple les tags, les téléversements, l’état de récurrence de l’événement, et si les réponses doivent être déplacées ou simplement laissées en place.
J’ai également une PR ouverte qui introduit une action Event (Événement) aux Workflows :
La PR de base ajoute Close event (Fermer l’événement) et Open event (Ouvrir l’événement), et j’ai un suivi empilé qui ajoute Set attendance (Définir la présence) :
L’action est structurée de manière à ce que d’autres opérations spécifiques aux événements puissent être ajoutées comme des suivis distincts lorsque cela a du sens.
Merci pour ces efforts, les conditions de fermeture peuvent être utiles, mais elles ne s’appliquent peut-être pas entièrement à la situation d’origine.
Une catégorie d’événements peut devenir volumineuse, surtout avec les événements récurrents, et il serait judicieux de prévoir un moyen d’archiver ou de déplacer automatiquement tout événement de sujet fermé depuis x jours vers une catégorie de sujets passés, ou de les archiver.
Mais cette question d’archivage dépend de la décision de faire en sorte que les événements récurrents deviennent des sujets individuels liés au sujet principal de l’événement.
J’ai ouvert une PR qui implémente cela sous forme de mode d’Événement récurrent optionnel :
Elle ajoute un paramètre de site discourse_post_event_recurring_topic_mode avec deux options :
reuse_topic — le comportement existant et par défautcreate_next_topic — conserve le sujet de l’occurrence terminée et crée un nouveau sujet pour l’occurrence suivanteAvec create_next_topic, lorsqu’une occurrence se termine, le sujet terminé est conservé avec son Événement épinglé à cette occurrence terminée et la récurrence supprimée. Un sujet successeur est ensuite créé pour la récurrence suivante, en conservant le titre, le corps, la catégorie, les balises et l’auteur d’origine, tout en faisant avancer les dates de l’Événement.
Les tests automatisés couvrent également la sémantique de bascule des RSVP : la participation récurrente « going » est transmise au sujet successeur, tandis que la participation ponctuelle reste avec l’occurrence terminée.
La bascule est également transactionnelle, de sorte que si la création du successeur échoue, l’occurrence reste en attente et peut être réessayée plutôt que d’être laissée à moitié terminée.
Cela implémente spécifiquement le modèle « créer le sujet suivant lorsque l’occurrence actuelle se termine ». Il ne génère pas encore de sujets individuels pour toutes les occurrences futures à l’avance, ce qui est le modèle alternatif mentionné plus haut par @opcourdis.
Le comportement existant reste par défaut, il s’agit donc d’une option à activer manuellement pour les sites qui souhaitent que le sujet d’Événement terminé serve d’archive.
Merci, ce modèle fonctionne déjà très bien pour les organisateurs, qui peuvent désormais savoir avec certitude qu’ils n’auront pas à recréer un événement à chaque fois. Il offre également la sécurité que les personnes ne s’abonneront pas à l’avance, car les organisateurs peuvent toujours annuler un événement pour certaines raisons.
Le modèle de création à l’avance que j’ai proposé fonctionne également dans de nombreux cas et compléterait votre modèle de successeur d’événement.
Au passage, concernant la PR du mode successeur d’événement :
1° Les personnes qui s’abonnent au nouvel événement sauront-elles toujours que le sujet/événement fait partie d’une série d’événements récurrents, comme c’est le cas pour l’événement/sujet original ?
2° L’invitation automatique des invités d’origine à l’événement est-elle une option à opt-out/opt-in ? Je dis cela parce qu’un événement futur n’est pas nécessairement un événement que vous souhaitez toujours promouvoir auprès des invités, puisque vous avez déjà promu l’événement et sa série une fois via le premier événement.
Oui, dans le sens où l’Événement successeur conserve la configuration de récurrence. Par exemple, dans le test de fumée de l’interface graphique, l’occurrence d’origine affichait Chaque jeudi, et après le basculement, le Sujet successeur affichait également Chaque jeudi, avec la date avancée à la semaine suivante.
Ce que cette PR n’ajoute pas, c’est une relation de série inter-Sujets distincte reliant le Sujet terminé et son successeur. Le Sujet terminé devient l’occurrence archivée à usage unique, tandis que le successeur perpétue la récurrence. Une relation explicite de série/parent entre ces Sujets pourrait constituer une amélioration distincte si cela s’avère utile.
Elle ne transfère pas automatiquement chaque invité/participant vers le nouvel Événement.
Le successeur n’hérite que des personnes qui avaient répondu going (y aller) avec la confirmation de présence récurrente/série activée. Quelqu’un qui a répondu going uniquement à l’occurrence individuelle reste sur le Sujet terminé et n’est pas ajouté au successeur.
Ainsi, à l’heure actuelle, le choix existant de répondre à la série agit en tant qu’opt-in pour être transféré vers les futurs Événements successeurs, plutôt que d’avoir un autre paramètre du site pour le contrôler.