Как структурировать Discourse для онлайн-курса?

Поддержка
1

@dax Актуально ли это в 2020 году, что нельзя ограничивать посты в теме пользователями из группы автора?

Мы хотим использовать Discourse вместе с нашей системой онлайн-обучения… мы хотим иметь один набор из примерно семи тем, через которые проходят разные когорты (группы) пользователей, так чтобы они могли видеть только посты в рамках своей группы. Нам бы хотелось использовать один набор тем, а не создавать одни и те же темы заново для каждой новой когорты.

Возможно, за это время появилась какая-то новая функция, которая делает это возможным? Спасибо за любые мысли.

2

Извините, ваш вопрос неясен и, похоже, не имеет отношения к делу.

Вы можете создавать категории, доступ к которым можно ограничить с помощью групп.

То, о чем просит @HappyGezim, — это функция «шепота» в теме, но это не входит в наш план развития.

3

@sam Спасибо за быстрый ответ! Я постараюсь прояснить нашу конкретную ситуацию:

  • У нас настроено четыре категории, по одной для каждого из четырех предлагаемых курсов.

  • В каждой категории (курсе) у нас примерно 5–10 тем, по одной на каждый «урок» курса… плюс несколько дополнительных, таких как «Технические вопросы», «Представьтесь» и т.д. По мере поступления каждого урока студентов просят внести вклад в соответствующую тему.

  • У нас будет много когорт студентов, проходящих эти курсы, и мы хотим ограничить публикации в теме только участниками их когорты («группы»). Таким образом, мы сохраняем категории и темы неизменными, а просто изменяем свойства пользователей, назначая их разным группам, которые мы могли бы создавать (?) через API и динамически назначать студентов (?)

Вот контекст, который привел меня к основному вопросу: «Внутри конкретной темы могу ли я создать сообщение, видимое только пользователям, входящим в определенную группу?»

4

Дэниел, у меня тоже есть курс, который я провожу через Discourse. Я использую категорию и подкатегорию, что позволяет максимально просто настраивать ограничения.

Категория: Курс Acme
Подкатегория: 2020-05 — Обсуждения курса

Студенты конкретной группы видят только одну подкатегорию.

Это не идеально, но работает!

5

@waffleslop Отлично. Спасибо. Вы создаёте эти подкатегории вручную каждый раз, когда появляется новая группа? (Или, возможно, через API?)

Я надеялся избежать этого, потому что для каждой группы мне придётся настраивать одни и те же 5–10 новых тем в подкатегории. У нас может быть несколько групп, одновременно проходящих один и тот же курс, что означает, что мне придётся проявить изобретательность в названиях. Так что, продолжая ваш пример…
2020-05-cohort-A Обсуждения курса
… или, возможно, есть способ создавать под-под-подкатегории — я пока этого не изучал.

Ещё раз спасибо за ваши мысли.

6

Сделайте эти категории доступными только для чтения.

Когда у вас появится новый поток, создайте для него новую категорию. Попросите студентов нажать на иконку :link: и затем выбрать «новая тема», чтобы создать тему для этого задания в категории потока. Я попросил их помечать каждое задание тегом задания, чтобы было проще отслеживать, выполнено ли задание и когда (я также создал значки, которые выдавались, если я «лайкал» их тему, и даже написал скрипт, который делал это для всех, создавал CSV-файл и загружал его в университетскую LMS, которую я не хотел использовать).

7

@pfaffman Спасибо за ваш вклад.

Моя идея заключалась в использовании подкатегорий для группировки потоков в рамках курса, но затем я увидел следующее в интерфейсе при создании подкатегории:

image
image1376×282 32.3 KB

Правильно ли я понимаю, что это означает невозможность использовать подкатегории для группировки потоков под курсом и затем применять разрешения групп для ограничения доступа только к этой подкатегории? @waffleslop, удалось ли вам ограничить доступ по подкатегории в вашем подходе? Возможно, я неправильно интерпретирую это сообщение в интерфейсе.

Если нельзя ограничить подкатегорию группой, @pfaffman, то, на мой взгляд, ваш подход (спасибо за объяснение), при котором для каждого потока создается новая категория, вероятно, является единственным вариантом.

Поскольку наши 10 или около того тем в каждом курсе довольно жестко фиксированы, имеют конкретные названия и нумерацию и т. д., я думаю, что буду создавать их через API каждый раз при создании нового потока в нашей системе. Таким образом, для каждого нового потока, создаваемого в нашей LMS, я буду использовать API для:

  • создания новой категории в Discourse для этого потока;
  • создания новой группы в Discourse с доступом к этой категории;
  • создания правильных 10 или около того тем в новой категории.
  • добавления любого студента, который присоединяется к потоку в нашей LMS, в соответствующую группу в Discourse (и удаления его, если он уходит).

Вы пробовали этот подход вместо того, чтобы полагаться на создание темы самим студентом? Меня беспокоит, что разные студенты могут создавать темы с немного разными названиями для одного и того же задания в курсе.

Не совсем понятно ваше предложение использовать «категории только для чтения» для решения одной из частей этой проблемы.

Большое спасибо за то, что нашли время изложить свои мысли!

8

Вот формат:

Категория: Курс Acme
Группы: 2020-01_cohort, 2020-05_cohort

Подкатегории:

  • 2020-01 — Обсуждения курса (Группа: 2020-01_cohort)
  • 2020-05 — Обсуждения курса (Группа: 2020-05_cohort)
9

Ага. Спасибо, @waffleslop. Понял, вы имеете в виду, что можно ограничить доступ к подкатегории группой, тем самым запретив доступ к другим подкатегориям. Я неправильно понял сообщение в интерфейсе, которое я скопировал выше. :zipper_mouth_face:

Поэтому наш подход, скорее всего, будет заключаться в использовании API для:

  • создания новой подкатегории в Discourse для каждой когорты,
  • создания новой группы в Discourse с доступом к этой подкатегории (а также к родительской категории, согласно сообщению в интерфейсе выше),
  • создания примерно 10 необходимых тем в новой подкатегории.
  • добавления в соответствующую группу в Discourse любого студента, который добавляется в когорту в нашей LMS (и удаления его, если он уходит).
10

Я почти уверен, что родительская категория может быть доступна только для чтения, а подкатегории ограничены только одной группой.

Вы можете это сделать, но в этом случае вам нужно будет создать (и поддерживать, если вы не сделаете это идеально с первого раза) категории только для чтения с инструкциями один раз, а при создании когорты вам нужно будет создать только одну подкатегорию.

Думаю, именно поэтому я использовал теги. Они отметят тему тегом задания, и тогда тема может иметь описательное название, но это не навредит, даже если они выберут неудачное название.

11

Для тех, кто следует описанному выше подходу — то есть использует подкатегории для каждой «группы» курса и повторяет темы обсуждений в каждой из них, — обязательно включите настройку «Разрешить дублирование названий тем». Иначе Discourse не позволит создавать одинаковые темы в каждой подкатегории.

12

Вот почему мне нравится моё решение: создавать одну категорию только для чтения с контентом, а студенты обсуждают этот контент, создавая новые темы в категории, специфичной для их группы.

13

Привет, @Daniel_McQuillen. Мне было интересно узнать, как прошла твоя курсовая программа. Я рассматриваю возможность запуска трёх курсов, каждый из которых будет включать несколько когорт, и хотел бы узнать о твоём опыте на данный момент.

Также скажи, планируешь ли ты ограничивать срок действия каких-либо из своих курсов или доступ к обсуждениям?

Заранее спасибо за ответ, Хантер

14

Привет, Хантер,

Сейчас мы находимся в бета-версии, но интеграция с Discourse проходит успешно. Мы используем интеграцию SSO для принудительного входа на нашем сайте. Это работает нормально, хотя я заметил следующее:

  1. Discourse не принимает имена пользователей со знаком «@» в них — он обрезает имя пользователя до части перед «@». Это может вызвать проблемы, если позже вы будете вызывать API Discourse, используя это имя пользователя в качестве аргумента. Discourse не распознает имя пользователя вроде someone@example.com, потому что в Discourse имя этого пользователя хранится как «someone». Простое решение — запретить использование знака «@» в именах пользователей на вашем сайте!

  2. Когда кто-то регистрируется на вашем сайте, вам нужно явно вызвать API Discourse для синхронизации пользователя SSO. Возможно, вы захотите выполнить некоторые действия с этим пользователем (например, добавить его в группу Discourse) до того, как он впервые посетит сайт Discourse (что автоматически синхронизирует SSO). У меня сайт на Django, поэтому я использую библиотеку pydiscourse, в которой есть метод sync_sso, делающий это довольно простым (pydiscourse · PyPI).

Да, мы будем отключать некоторые из наших курсов. В этом случае сервер будет вызывать API Discourse и удалять пользователя из общей группы для этого курса, а также из группы, посвященной его когорте в рамках этого курса.

Я создал таблицы на своем сайте на Django, которые отслеживают эти группы «курсов» и различные группы «когорт» внутри каждого курса. Поэтому я использую эту информацию при добавлении/удалении студентов и т.д.:

image
image1562×952 84.6 KB