Actuellement, les entrées d’événements font toujours partie de l’élément d’interface du calendrier, qui peut être ajouté à une catégorie. Il n’existe aucun moyen de restreindre un événement à un groupe d’utilisateurs spécifique. Dans une configuration Discourse multi-communauté, toutes les communautés voient tous les événements de toutes les autres communautés. Si vous affichez les événements Discourse en externe sur un site web via un appel API tel que
Il devrait y avoir une option pour créer des événements « internes » qui ne sont affichés que dans un groupe d’utilisateurs. Ces événements ne devraient pas être lisibles via la requête ICS API « générale ». Au lieu de cela, ils ne devraient être disponibles que grâce à une « clé API de groupe » spéciale et supplémentaire, ou à une autre forme de restrictions sécurisées. Le cas d’usage est un choix entre des événements « publics » et des événements « privés », visibles et modifiables uniquement au sein d’un groupe d’utilisateurs spécifique.
Correction : il semble que les événements créés au sein d’un groupe respectent déjà les autorisations du groupe sur le calendrier affiché dans les catégories restreintes au groupe. La seule chose qui manque est une forme de restriction pour les appels API via « https://example.discourse.org/discourse-post-event/events.ics?user_api_key=[xxxxx] ».
La création d’un utilisateur appartenant uniquement au groupe dont vous avez besoin, et la génération de l’URL d’abonnement au calendrier à partir des préférences de cet utilisateur, fonctionneraient-ils dans votre cas ? Le flux ne contiendrait que les événements visibles par cet utilisateur.
Hmmm, je ne suis pas sûr. Ça ressemble à une solution de contournement, mais pas vraiment à une « solution »
Toutes les personnes au sein d’un groupe spécifique à une communauté devraient pouvoir créer des événements. Et les voir également lorsqu’elles accèdent à la catégorie « de leur » communauté. Cela fonctionne déjà très bien dans notre configuration actuelle avec 5 communautés différentes. Nous utilisons les permissions de catégories suivantes :
une catégorie par groupe de communauté. Celle-ci dispose de « lecture globale en lecture seule » et de « lecture/création/réponse communautaire ». Cette catégorie est fédérée via AP pour permettre aux personnes sans compte Discourse de voir les événements et également pour permettre l’intégration du calendrier Discourse dans des systèmes tiers (par exemple WordPress avec le plugin ICS)
un certain nombre de sous-catégories internes. Ces sous-catégories ne disposent que des permissions « lecture/création/réponse communautaire ». Elles sont invisibles sans les permissions de groupe appropriées.
Les seuls manques sont
la requête ics actuelle présente TOUS les événements
un moyen de demander uniquement les événements d’une communauté particulière via ICS/API.
Il existe deux niveaux d’accès pour les clés API : « utilisateur unique » ou « tous les utilisateurs ». Les clés API que nous utilisons actuellement pour la requête ICS sont au niveau « tous les utilisateurs ».
Ainsi, pour résoudre ce problème, il nous faudrait probablement des clés API au niveau « utilisateur unique ». Et l’utilisateur sélectionné ne devrait que faire partie du groupe de permissions « communautés », rien d’autre.
Je vais vérifier cela. Peut-être que cela pourrait résoudre le problème …