@dax Est-ce toujours le cas en 2020 qu’on ne peut pas limiter les publications dans un sujet aux utilisateurs du groupe de l’auteur ?
Nous souhaitons utiliser Discourse avec notre système d’apprentissage en ligne… nous voulons avoir un ensemble d’environ sept sujets que différentes cohortes (groupes) d’utilisateurs parcourent, de sorte qu’ils ne puissent voir que les publications au sein de leur groupe. Nous préférons avoir un seul ensemble de sujets plutôt que de recréer les mêmes sujets à chaque nouvelle cohorte.
Peut-être qu’une autre nouvelle fonctionnalité est apparue entre-temps qui rend cela possible ? Merci pour vos réflexions.
Désolé, votre question est peu claire et semble sans rapport.
Vous pouvez créer des catégories, et celles-ci peuvent être sécurisées à l’aide de groupes.
Ce que demande @HappyGezim, c’est une fonctionnalité personnalisée de « chuchotement » au sein d’un sujet, mais cela ne figure pas sur notre feuille de route.
@sam Merci pour votre réponse rapide ! Je vais essayer de clarifier notre cas précis :
Nous avons configuré quatre catégories, une pour chacun des quatre cours que nous proposons.
Dans chaque catégorie (cours), nous avons environ 5 à 10 sujets, un pour chaque « Leçon » du cours… plus quelques-uns supplémentaires comme « Questions techniques », « Présentez-vous », etc. À chaque nouvelle leçon, les étudiants sont invités à contribuer au sujet correspondant.
Nous aurons de nombreuses cohortes d’étudiants suivant ces cours, et nous souhaitons limiter les publications dans un sujet à leur « groupe » de cohorte. Ainsi, nous gardons les mêmes catégories et sujets statiques et nous modifions simplement les propriétés des utilisateurs pour les assigner à différents groupes, que nous pourrions créer (?) via l’API et assigner dynamiquement aux étudiants (?)
Voilà donc le contexte qui m’a amené à m’intéresser à la question principale : « Dans un sujet spécifique, puis-je créer un message visible uniquement par les utilisateurs appartenant à un groupe spécifique ? »
Daniel, j’ai aussi un cours que je gère via Discourse. J’utilise une catégorie + une sous-catégorie qui permettent de restreindre l’accès le plus facilement possible.
Catégorie : Cours Acme
Sous-catégorie : 2020-05 - Discussions du cours
Les étudiants d’une cohorte spécifique ne voient qu’une seule sous-catégorie.
@waffleslop Génial. Merci. Créez-vous manuellement ces sous-catégories à chaque nouvelle cohorte ? (ou peut-être via une API ?)
J’espérais éviter cela car, pour chaque cohorte, je devrai configurer les mêmes 5 à 10 nouveaux sujets dans une sous-catégorie. Nous pourrions également avoir plusieurs cohortes simultanées en cours pour un même cycle de formation, ce qui signifierait que je devrais faire preuve de créativité dans le nommage. Donc, en m’inspirant de votre exemple … 2020-05-cohort-A Discussions du cours
… ou peut-être existe-t-il un moyen de créer des sous-sous-sous-catégories, je n’ai pas encore examiné cette option.
Lorsque vous recevez une nouvelle promotion, créez une nouvelle catégorie dédiée à cette promotion. Demandez aux étudiants de cliquer sur l’icône puis sur « nouveau sujet » pour créer un nouveau sujet pour cette tâche dans la catégorie de la promotion. J’ai demandé à chacun d’étiqueter chaque tâche avec un tag de tâche afin de faciliter le suivi de qui a réalisé la tâche et quand (j’ai également créé des badges attribués si je « likais » leur sujet, et j’ai même écrit un script pour le faire pour tous, générer un fichier CSV, et le télécharger sur le LMS de l’université que je ne voulais pas utiliser).
Mon idée initiale était d’utiliser des sous-catégories pour regrouper les cohortes sous un cours, mais j’ai ensuite remarqué ceci dans l’interface lors de la création d’une sous-catégorie :
Ai-je raison de penser que cela signifie qu’il est impossible d’utiliser des sous-catégories pour regrouper les cohortes sous un cours, puis d’utiliser les permissions de groupe pour les limiter à cette sous-catégorie ? @waffleslop, avez-vous pu limiter par sous-catégorie dans votre approche ? Peut-être que j’ai mal interprété ce message de l’interface.
Si vous ne pouvez pas limiter une sous-catégorie à un groupe, @pfaffman, je pense que votre approche (merci pour les explications), où vous créez une nouvelle catégorie pour chaque cohorte, est probablement la seule option.
Puisque nos 10 ou quelques sujets dans chaque cours sont assez fermement fixés, avec une numérotation et un nommage spécifiques, etc., je pense créer ceux-ci via l’API à chaque fois qu’une nouvelle cohorte est créée dans notre système. Ainsi, pour chaque nouvelle cohorte que nous créons dans notre LMS, j’utiliserai l’API pour :
créer une nouvelle catégorie dans Discourse pour cette cohorte,
créer un nouveau groupe dans Discourse avec accès à cette catégorie,
créer les 10 ou quelques sujets corrects dans la nouvelle catégorie.
à chaque fois qu’un étudiant est ajouté à une cohorte dans notre LMS, l’ajouter au groupe correspondant dans Discourse (et le retirer s’il part).
Avez-vous déjà essayé cette approche plutôt que de laisser l’étudiant créer le sujet lui-même ? Je me demande ce qu’il advient si différents étudiants créent des sujets légèrement différents pour le même devoir dans le cours.
Je ne suis pas sûr de votre suggestion d’utiliser des « catégories en lecture seule » pour un aspect de ce problème.
Merci beaucoup d’avoir pris le temps de rédiger vos réflexions !
Aha. Merci @waffleslop. Ok, donc vous dites qu’il est possible de limiter une sous-catégorie à un groupe, interdisant ainsi l’accès aux autres sous-catégories. Je malinterprète le message de l’interface utilisateur que j’ai copié ci-dessus.
Par conséquent, notre approche consistera probablement à utiliser l’API pour :
créer une nouvelle sous-catégorie dans Discourse pour chaque cohorte
créer un nouveau groupe dans Discourse avec accès à cette sous-catégorie (ainsi qu’à la catégorie parente, conformément au message de l’interface utilisateur ci-dessus)
créer les 10 ou quelques sujets appropriés dans la nouvelle sous-catégorie.
chaque fois qu’un étudiant est ajouté à une cohorte dans notre LMS, l’ajouter au groupe correspondant dans Discourse (et le retirer s’il quitte la cohorte)
Je suis presque certain que le parent peut être en lecture seule tandis que les sous-catégories sont restreintes à un seul groupe.
Vous le pouvez, mais de cette manière, vous n’avez besoin de créer (et de maintenir, sauf si vous obtenez le résultat parfait du premier coup) les catégories en lecture seule avec les instructions qu’une seule fois. Ensuite, lorsque vous créez une cohorte, vous devez créer uniquement la sous-catégorie correspondante.
Je pense que c’est pourquoi j’ai utilisé les étiquettes. Ils étiquetteront le sujet avec l’étiquette du devoir, et le sujet pourra alors être descriptif. Cela ne posera aucun problème même s’ils choisissent un nom peu pertinent.
Pour toute personne adoptant l’approche décrite ci-dessus, c’est-à-dire en utilisant des sous-catégories pour chaque « cohorte » de cours et en répétant les sujets de discussion dans chacune, assurez-vous d’activer le paramètre « autoriser les titres de sujets en double », sinon Discourse ne vous permettra pas de répéter les mêmes sujets dans chaque sous-catégorie.
C’est l’une des raisons pour lesquelles j’aime ma solution consistant à avoir une seule catégorie en lecture seule contenant le contenu, et à ce que les étudiants discutent de ce contenu en créant de nouveaux sujets dans la catégorie spécifique à leur cohorte.
Bonjour @Daniel_McQuillen. Je me demandais comment s’est déroulé votre cours. Je songe à organiser trois cours, chacun comportant plusieurs cohortes, et je suis intéressé par votre expérience à ce jour.
Par ailleurs, expirez-vous certains de vos cours ou l’accès aux discussions ?
Nous sommes actuellement en version bêta, mais l’intégration avec Discourse se déroule bien. Nous utilisons l’intégration SSO pour imposer la connexion sur notre site. Cela fonctionne correctement, bien que j’aie remarqué les points suivants :
Discourse n’accepte pas les noms d’utilisateur contenant le signe « @ »… il tronque le nom d’utilisateur pour ne garder que la partie avant le « @ ». Cela peut poser problème si vous appelez ultérieurement les API de Discourse en utilisant ce nom d’utilisateur comme argument. Discourse ne reconnaîtra pas un nom d’utilisateur tel que someone@example.com, car dans Discourse, le nom d’utilisateur de cet utilisateur est stocké sous la forme « someone ». Une solution simple consiste à interdire les signes « @ » dans vos propres noms d’utilisateur !
Lorsqu’une personne s’inscrit sur votre propre site, vous devez appeler explicitement l’API de Discourse pour synchroniser l’utilisateur SSO, car vous pourriez souhaiter effectuer certaines actions avec cet utilisateur (par exemple, l’ajouter à un groupe Discourse) avant qu’il ne visite le site Discourse pour la première fois (ce qui synchroniserait automatiquement le SSO). Mon site est basé sur Django, j’utilise donc la bibliothèque pydiscourse, qui propose une méthode sync_sso rendant cela assez simple (pydiscourse · PyPI).
Oui, nous allons expirer certains de nos cours. Dans ce cas, le serveur appellera l’API de Discourse pour retirer l’utilisateur du groupe général de ce cours, ainsi que du groupe dédié à sa cohorte au sein de ce cours.
J’ai créé des tables dans mon site Django qui suivent ces groupes de « cours » et les différents groupes de « cohorte » au sein de chaque cours. J’utilise donc ces informations lors de l’ajout ou de la suppression d’étudiants, etc. :
puis sur « nouveau sujet » pour créer un nouveau sujet pour cette tâche dans la catégorie de la promotion. J’ai demandé à chacun d’étiqueter chaque tâche avec un tag de tâche afin de faciliter le suivi de qui a réalisé la tâche et quand (j’ai également créé des badges attribués si je « likais » leur sujet, et j’ai même écrit un script pour le faire pour tous, générer un fichier CSV, et le télécharger sur le LMS de l’université que je ne voulais pas utiliser).
