@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.
Para quem adota a abordagem descrita acima — ou seja, usar subcategorias para cada ‘cohort’ do curso e repetir os tópicos de discussão em cada uma —, certifique-se de ativar a configuração ‘permitir títulos de tópicos duplicados’. Caso contrário, o Discourse não permitirá que você repita os mesmos tópicos em cada subcategoria.
Essa é parte da razão pela qual gosto da minha solução de ter uma única categoria somente para leitura com o conteúdo e fazer com que os estudantes discutam esse conteúdo com novos tópicos na categoria específica de cada turma.
Olá @Daniel_McQuillen. Fiquei curioso sobre como foi seu curso. Estou pensando em oferecer três cursos, cada um com múltiplas turmas, e gostaria de saber sua experiência até agora.
Além disso, você está encerrando algum de seus cursos ou o acesso às discussões?
Atualmente estamos em fase beta, mas a integração com o Discourse está indo bem. Estamos usando a integração SSO para forçar o login no nosso site. Isso tem funcionado bem, embora eu tenha notado:
O Discourse não aceita nomes de usuário com o símbolo “@”… ele truncar o nome de usuário apenas na primeira parte antes do “@”. Isso pode causar problemas se você posteriormente chamar as APIs do Discourse usando esse nome de usuário como argumento. O Discourse não reconhecerá um nome de usuário como someone@example.com, pois no Discourse o nome de usuário desse usuário é armazenado como “someone”… uma maneira fácil de contornar isso é não permitir o uso do símbolo “@” nos seus próprios nomes de usuário!
Quando alguém se registra no seu próprio site, você precisa chamar explicitamente a API do Discourse para sincronizar o usuário SSO, pois talvez queira realizar ações com esse usuário (por exemplo, adicioná-lo a um grupo do Discourse) antes de ele visitar o site do Discourse pela primeira vez (o que sincronizaria automaticamente o SSO). Tenho um site baseado em Django, então estou usando a biblioteca pydiscourse, que possui um método sync_sso que torna isso bastante fácil (pydiscourse · PyPI)
Sim, vamos expirar alguns dos nossos cursos, caso em que o servidor chamará a API do Discourse para remover o usuário do grupo geral daquele curso, bem como do grupo dedicado à sua turma dentro desse grupo.
Criei tabelas no meu site Django que acompanham esses grupos de “cursos” e os vários grupos de “turmas” dentro de cada curso. Então, uso essas informações ao adicionar/remover alunos, etc.:
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).
