Cela permettrait de filtrer les sujets ayant un événement associé via le plugin Events, en utilisant la route
/filteret le plugin Custom Topic Lists.
Le problème
Le plugin Discourse Events crée des sujets d’événements riches, mais il n’existe actuellement aucun moyen de les isoler des sujets non liés à des événements à l’aide du langage de requête de filtre des sujets.
Les solutions de contournement existantes ont toutes des inconvénients :
- La route
/upcoming-eventsaffiche les événements sous forme de calendrier, et non de liste de sujets filtrable - bien qu’elle devrait peut-être le faire !!! - Le composant de thème Calendrier des événements sur listes personnalisées possède un paramètre côté client « N’afficher que les sujets avec événements », mais il agit après le chargement de la liste — ce n’est pas un vrai filtre côté serveur, il ne fonctionne pas bien avec la pagination et peut se comporter de manière incohérente
- Les approches basées sur des conventions (catégories dédiées, tags obligatoires) nécessitent une discipline stricte de gestion du contenu
Solution proposée
Le plugin Events devrait étendre le DSL de filtre des sujets avec un filtre event:, en suivant le même modèle déjà utilisé par le plugin Solved (status:solved / status:unsolved) et le plugin Assign (?assigned=username).
Syntaxe d’exemple :
event:yes # Sujets avec un événement associé
event:no # Sujets sans événement (via -event:yes)
-category:announcements event:yes # Événements en dehors des annonces
tag:meetup event:yes order:created # Sujets tagués meetup ayant des événements, triés par plus récent
Une variante status:events pourrait également être envisagée pour la cohérence avec l’espace de noms status: existant, mais event: est plus naturel pour le cas d’usage principal.
Pourquoi c’est la bonne couche
La documentation du filtre stipule explicitement :
Le plugin Events stocke déjà des données structurées d’événements (date de début, date de fin, statut, RSVP) dans des tables dédiées. Un filtre côté serveur peut interroger cela efficacement — ce qu’un composant côté client ne peut tout simplement pas faire.
Exemple de cas d’usage
En tant que gestionnaire de communauté, je souhaite une URL partageable — lien utilisable dans ma barre latérale, intégrable via Custom Topic Lists et utilisable dans le composant de thème Filtered Topic Lists — qui affiche de manière fiable tous les sujets de n’importe quelle catégorie ayant un événement associé, triés par date de l’événement.
Aujourd’hui, je ne peux pas construire cette requête avec confiance. Avec un filtre event:, je pourrais :
event:yes order:created
…et obtenir une liste de sujets propre, paginée et tenant compte des autorisations, de tous les événements sur mon site.