@dax Is still the case in 2020, that you can’t limit posts in a topic to users in the poster’s group?
We want to use Discourse with our online learning system…we want to have one set of seven or so topics that different cohorts (groups) of users move through, such that they can only see posts within their group. We’re rather have one set of topics rather than creating the same topics again and again each new cohort.
Perhaps another new feature has arrived in the meantime that make this possible? Thanks for any thoughts.
@sam Thanks for your quick response! I’ll try to clarify with our exact scenario:
We have four categories set up, one for each of the four courses we offer.
In each category (course) we have approximately 5 to 10 topics, one for each “Lesson” in the course…plus a few extra like “Technical Questions”, “Introduce Yourself” etc. As each Lesson arrives, students are asked to make contributions to the related topic.
We are going to have lots of cohorts of students moving through these courses, and want to limit posts in a topic to their cohort “group.” That way we keep the same categories and topics static and just modify user properties to assign them to different groups, which we could create (?) via the API and dynamically assign students (?)
So that’s the context that led me to latch on to the top question “Inside a specific topic, can I create a message that’s only visible to users that belong to a specific group?”
@waffleslop Awesome. Thanks. Do you create those sub categories manually each time you have a new cohort? (or perhaps via API?)
I was hoping to avoid that because for every cohort I’ll have to set up the same 5 to 10 new topics in a subcategory. We may have a bunch of simultaneous cohorts going through any one run of the course too, which means I’d have to get creative with naming. So building on your example … 2020-05-cohort-A Course Conversations
… or perhaps there’s a way to create sub-sub-subcategories haven’t looked at that yet.
When you get a new cohort, create a new category for the cohort. Have students click the icon and then “new topic” to create a new topic for that assignment in the cohort category. I had them tag each assignment with an assignment tag to make it easier to track whether and when people had done the assignment (and I created badges that were awarded if I “liked” their topic and even made a script to do this for all of them, create a CSV, and upload it to the university LMS that I didn’t want to use).
Am I correct in thinking this means there’s no way to use subcategories to group cohorts beneath a course and then use group permissions to limit them to that subcategory? @waffleslop were you able to limit by subcategory in your approach? Maybe I’m reading that UI message wrong.
If you can’t limit a subcategory to a group, @pfaffman I think your approach (thanks for explaining) where you create a new category for each cohort is probably the only option.
Since our 10 or so topics in each course are pretty firmly fixed, have specific naming and numbering, etc. I’m thinking I will create those via the API each time a new cohort is created in our system. So for each new cohort we create in our LMS I’ll use the API to:
create a new category in Discourse for that cohort
create a new group in Discourse with access to that category
create the correct 10 or so topics in the new category.
anytime a student is added to a cohort in our LMS, add them to the correct group in Discourse (and remove them if they leave)
Did you ever try this approach instead of relying on the student to create the topic themselves? I’m wondering about different students creating slightly different named topics for the same assignment in the course.
Unclear on your suggestion to use “read-only categories” for an aspect of this problem.
Thanks much for taking the time to write down your thoughts!
Aha. Thanks @waffleslop. Ok, so you’re saying you can limit subcategory to group and thereby disallow other subcategory access. I’m misunderstanding that UI message I copied above.
Therefore our approach will probably be to use the API to:
create a new subcategory in Discourse for each cohort
create a new group in Discourse with access to that subcategory (as well as parent category, per UI message above)
create the correct 10 or so topics in the new subcategory.
anytime a student is added to a cohort in our LMS, add them to the correct group in Discourse (and remove them if they leave)
I’m pretty sure that the parent can be read-only the the subcategories are restricted just to the one group.
You can, but this way you need to create (and maintain unless you get them perfect the first time) the read-only categories with the instructions only once, and when you create a cohort, you need to create just the one subcategory.
I think that’s why I used tags. They’ll tag the topic with the assigment tag and then the topic can be descriptive but it won’t hurt anything if they choose a stupid one.
For anybody taking the approach outlined above – i.e. using subcategories for each course ‘cohort’ and repeating the discussion topics in each – make sure to enable the “allow duplicate topic titles” setting, otherwise Discourse won’t let you repeat the same topics in each each subcategory.
This is part of why I like my solution of having a single read only category with the content and having students discuss that content with new topics in the cohort-specific category.
Ciao @Daniel_McQuillen. Ero curioso di sapere come è andata il tuo corso. Sto valutando di gestire tre corsi, ognuno con più cohort, e sono interessato alla tua esperienza finora.
Inoltre, stai scadendo alcuni dei tuoi corsi o l’accesso alle discussioni?
Siamo attualmente in fase beta, ma l’integrazione con Discourse sta procedendo bene. Stiamo utilizzando l’integrazione SSO per obbligare l’accesso al nostro sito. Funziona senza problemi, anche se ho notato quanto segue:
Discourse non accetta nomi utente contenenti il simbolo “@”… tronca il nome utente alla sola parte precedente la “@”. Questo può causare problemi se in seguito si chiamano le API di Discourse usando quel nome utente come argomento. Discourse non riconoscerà un nome utente come someone@example.com perché in Discourse il nome utente di quell’utente viene memorizzato come “someone”… un modo semplice per evitare questo problema è non permettere l’uso del simbolo “@” nei propri nomi utente!
Quando qualcuno si registra sul proprio sito, è necessario chiamare esplicitamente le API di Discourse per sincronizzare l’utente SSO, poiché potresti voler eseguire alcune operazioni su quell’utente (ad esempio, aggiungerlo a un gruppo di Discourse) prima che visiti per la prima volta il sito di Discourse (cosa che sincronizzerebbe automaticamente l’SSO). Ho un sito basato su Django, quindi sto utilizzando la libreria pydiscourse, che offre un metodo sync_sso che rende tutto molto semplice (pydiscourse · PyPI)
Sì, disattiveremo alcuni dei nostri corsi; in tal caso, il server chiamerà le API di Discourse per rimuovere l’utente dal gruppo generale relativo a quel corso, nonché dal gruppo dedicato alla sua coorte all’interno di tale corso.
Ho creato delle tabelle nel mio sito Django che tengono traccia di questi gruppi “corso” e dei vari gruppi “coorte” all’interno di ciascun corso. Utilizzo quindi queste informazioni quando aggiungo o rimuovo studenti, ecc.:
icon and then “new topic” to create a new topic for that assignment in the cohort category. I had them tag each assignment with an assignment tag to make it easier to track whether and when people had done the assignment (and I created badges that were awarded if I “liked” their topic and even made a script to do this for all of them, create a CSV, and upload it to the university LMS that I didn’t want to use).
