@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.
مرحباً @Daniel_McQuillen. كنت أتساءل عن سير دورتك التدريبية. أنا أفكر في تشغيل ثلاث دورات تدريبية، كل منها تضم عدة دفعات، وكنت مهتمًا بتجربتك حتى الآن.
أيضًا، هل تنوي إنهاء صلاحية أي من دوراتك أو الوصول إلى المناقشات؟
نحن حاليًا في مرحلة الاختبار التجريبي، وتكامل Discourse يسير على ما يرام. نستخدم تكامل SSO لإجبار المستخدمين على تسجيل الدخول في موقعنا. لقد عمل هذا بشكل جيد، رغم أنني لاحظت ما يلي:
لا يقبل Discourse أسماء مستخدمين تحتوي على رمز “@”… فهو يقص اسم المستخدم ليحتوي فقط على الجزء الأول قبل “@”… وهذا قد يسبب مشاكل إذا قمت لاحقًا باستدعاء واجهات برمجة تطبيقات Discourse باستخدام ذلك الاسم كمُعامِل. لن يتعرف Discourse على اسم مستخدم مثل someone@example.com لأن اسم المستخدم المخزن في Discourse هو someone فقط… الحل السهل هو منع استخدام رمز “@” في أسماء المستخدمين الخاصة بك!
عندما يسجل شخص ما في موقعك، يجب عليك استدعاء واجهة برمجة تطبيقات Discourse صراحةً لمزامنة مستخدم SSO، حيث قد ترغب في القيام بأشياء مع هذا المستخدم (مثل إضافته إلى مجموعة Discourse) قبل زيارته لموقع Discourse لأول مرة (وهو ما سينشط المزامنة التلقائية لـ SSO). لدي موقع مبني على Django، لذا أستخدم مكتبة pydiscourse، وهناك طريقة sync_sso تجعل هذا الأمر سهلاً للغاية (pydiscourse · PyPI)
نعم، سنقوم بإنهاء صلاحية بعض الدورات التدريبية لدينا، وفي هذه الحالة سيقوم الخادم باستدعاء واجهة برمجة تطبيقات Discourse لإزالة المستخدم من المجموعة العامة لتلك الدورة، وكذلك من المجموعة المخصصة لدفعته ضمن هذه الدورة.
لقد أنشأت جداول في موقع Django الخاص بي تتتبع مجموعات “الدورات” هذه والمجموعات المختلفة لـ “الدفعات” داخل كل دورة. لذا أستخدم هذه المعلومات عند إضافة/إزالة الطلاب، وما إلى ذلك:
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).
