По сути, мы надеемся создать группы для управления правами на публикацию сообщений внутри темы, но при этом хотим, чтобы каждый пользователь и незарегистрированные гости могли читать опубликованное.
Есть ли способ реализовать это?
Понимаю, что это можно сделать для категории, но мы надеемся избежать создания новой категории, поскольку все эти темы уже аккуратно распределены по категориям и подкатегориям.
Мы очень надеемся на возможность ограничивать ответы (и лайки, кстати) для каждой темы отдельно.
Насколько я знаю, из коробки это невозможно. Но я бы хотел ошибаться.
Возможно, вам стоит архивировать эти темы.
Не понимаю, как это всё ещё позволяет пользователям определённой группы публиковать там сообщения…
Ах, извините, @orangeandblack5, я не учёл ваш исходный вопрос, а отвечал только на эту часть:
Давайте начнём сначала…
В Discourse права групп устанавливаются на уровне категории, а не уровня сообщения, поэтому, насколько я знаю, сделать то, что вы просите, невозможно.
Мне интересно: почему вы не хотите, чтобы те, кто может читать темы, могли их лайкать? Я подумал об архивировании, возможно, вы хотели их «заморозить», но звучит так, будто вы хотите, чтобы одни пользователи могли ставить лайки, а другие — нет. Мне очень нравится узнавать, как люди используют Discourse в своих сообществах! 
Для нас возможность публиковать сообщения гораздо важнее, чем возможность ставить лайки, но в целом мы используем Discourse для проведения различных онлайн-игр и обсуждений, в которых люди должны зарегистрироваться, чтобы участвовать. По правилам запрещено публиковать сообщения в игре, в которой вы на самом деле не участвуете, однако у нас нет программного обеспечения для принудительного соблюдения этого правила. Поэтому иногда новые пользователи путаются и случайно нарушают работу, хотя им следовало бы зарегистрироваться для участия в будущей теме.
Было бы здорово иметь возможность разрешить всем читать все темы, но запрещать публиковать сообщения в конкретной теме тем, кто не зарегистрировался для участия в ней!
Я также считаю, что единственный способ добиться этого без написания собственного кода — создать отдельную подкатегорию для каждой игры или обсуждения, которое вы хотите ограничить. Это может показаться громоздким, но поскольку вам в любом случае приходится настраивать отдельную группу каждый раз, дополнительные ручные усилия будут незначительными. В любом случае, при такой настройке пользовательский опыт будет чистым:
- категория: игры
разрешение: все могут читать - подкатегория: игра-A
разрешение: только группа «игра-A» может отвечать
Таким образом, темы из «игры-A» будут видны всем, но любой пользователь, не являющийся участником группы «игра-A», открывший тему, не сможет в ней отвечать.
Если вы хотите максимально чистый интерфейс, и это соответствует вашей архитектуре, вы даже можете скрыть соответствующие значки подкатегорий из интерфейса с помощью CSS. В этом случае подкатегории будут использоваться исключительно для управления правами доступа, а не для навигации.
Проблема в том, что мы уже используем подкатегории для сортировки.
Мы хотя бы рассмотрим этот вариант, но это действительно неидеально, так как нам пришлось бы убрать целый уровень сортировки и организации, что могло бы значительно усложнить навигацию по сайту, особенно для новых пользователей.
Я подозреваю, что для организации этого вам следует использовать теги. См. Пора поговорить о тегах.
Простого способа настроить права доступа для каждой темы не будет.
Интересно, есть ли способ реализовать публикацию страниц для личных сообщений?
Я так не думаю. Но вы можете опубликовать их в категории, куда люди могут писать, а затем скрыть их из списка.
Это не связано с кейсом ОП, но я администрирую форум с одной категорией, доступной только анонимно, где пользователи могут обсуждать профессиональные вопросы, не раскрывая свои имена другим (хотя администраторы знают, кто что написал, если кто-то нарушает правила). Было бы здорово иметь возможность ограничивать лайки только анонимными пользователями.
У меня возникла точно такая же ситуация: мы используем Discourse как часть нашей собственной LMS, и нам иногда нужно ограничивать доступ к теме курса для определённых групп студентов.
Поэтому единственный способ сделать это (как объяснялось выше) — создать категорию для курса, а затем подкатегорию для каждой группы, которой требуется ограничение доступа… после чего копировать каждую тему в соответствующую подкатегорию. Это довольно утомительно, особенно учитывая необходимость поддерживать модели на нашей стороне, отражающие такую структуру, и писать код для синхронизации данных.
Было бы намного круче, если бы мы могли ограничивать доступ к сообщениям в каждой теме для определённых групп.
Должен ли каждый участник отвечать на сообщения всех остальных когорт?
Если бы я настраивал это, я бы разместил материалы в категории, где нельзя отвечать, просто как справочные материалы.
Затем я бы отправил групповое личное сообщение со ссылкой на материалы и проводил обсуждение там.
Так вы просто организуете когорты в группы и сможете легко использовать материалы повторно.
Так работают личные сообщения! 
Но это не относится к публичным темам.
@maiki Вау! Я об этом не знал. Спасибо, что поделились!!!
Однако при текущей стратегии всё работает по принципу «настроил и забыл». Когда курс создан, мы можем создать тему и подкатегорию для когорты по умолчанию, а затем наполнить их нужными темами. Если добавляется новая когорта, мы создаём новую группу и подкатегорию и копируем туда темы.
После этого можно забыть об этом и просто обрабатывать уведомления о активностях через обратный вызов (callback).
С подходом, который вы описали, будет ли это требовать больше ручной работы? «Отправка группового личного сообщения» звучит как действие, которое происходит в течение жизни курса. Если новый студент записывается на существующий курс и попадает в определённую когорту, мы можем добавить его в соответствующую группу в Discourse, и тогда у него будет доступ к существующей подкатегории (для этой когорты) и копиям всех тем. В таком случае, будут ли они автоматически добавлены в существующее «групповое личное сообщение», так что рабочий процесс не изменится?
Будет ли интерфейс выглядеть так же? Сейчас у нас просто есть тема, а под ней все посты (для конкретной когорты, если необходимо), в соответствии с «обычным» интерфейсом Discourse.
Честно говоря, я ненавижу необходимость создавать подкатегории и копировать все темы каждый раз при создании новой когорты на нашей стороне, а также управлять этим. Поэтому идея с прямым личным сообщением кажется привлекательной. Но у меня есть опасение, что использование «личного сообщения» для выполнения всего, что может делать категория с темами, где-то упускает что-то важное.
Я не могу до конца представить, как это будет выглядеть для пользователей.
Я лишь знаю, что часто ссылаюсь на темы или использую шаблоны для повторного использования контента в личных сообщениях, когда работаю с повторно используемым контентом.
Если вы немного подробнее расскажете о том, что вы делаете, с примерами тем и ответов студентов, чтобы мы могли увидеть опыт работы с когортами, я с радостью помогу придумать, как реализовать это с помощью личных сообщений.
Я создал категорию только для чтения с заданиями и попросил студентов отвечать, используя функцию «ответ как связанная тема», когда они «отвечали» на задание, публикуя сообщения в основной категории класса. Не уверен, насколько легко сейчас найти функцию «ответ как связанная тема» в сообщениях только для чтения.
Спасибо @pfaffman и @maiki за ваши мысли. Мы интегрировали темы, используя API для получения последних сообщений по теме и отображения их непосредственно на соответствующей странице модуля курса в нашей LMS:
Затем при нажатии кнопки «Присоединиться к обсуждению» пользователь попадает на страницу темы в категории курса и подкатегории для своей группы (когорты), что ограничивает доступ только к комментариям участников его группы:
Немного странно то, что эта архитектура просачивается в пользовательский интерфейс, например, в этот заголовок:
и в навигацию:
Это заставляет студента разбираться, зачем существует категория верхнего уровня, затем одна подкатегория для «Тем курса» (это та, что для его группы), и ещё одна для «Общего обсуждения» (это та, что для всех групп в курсе). Если они начнут переходить по ссылкам, могут немного запутаться.
Иногда группы (когорты) — это скорее механизм административной группировки, а не то, что волнует студента, что делает эту схему «категория/подкатегория» ещё более запутанной. «Почему нет просто одной категории для всех тем курса?»
Кроме того, как я уже упоминал, такая настройка означает, что нам нужно дублировать все темы при создании каждой группы, удалять эту подгруппу при удалении группы или обновлять каждую подкатегорию при создании/обновлении/удалении темы.