Я хотел бы иметь около 20 000 групп в моём экземпляре Discourse. Это вообще возможно и как-то повлияет ли это на производительность сайта?
Сколько пользователей будет у вас?
Какую проблему решает 20 000 групп?
Вот ситуация. Я использую Discourse для создания платформы обсуждения научных статей. Каждая статья представлена тегом с её идентификатором. Все темы, созданные под этим тегом, отображаются на странице тега для соответствующей статьи.
Проблема заключается в следующем:
У меня есть ручной процесс одобрения авторов статей, загружаемых в систему. Я хочу предоставить им возможность редактировать сообщения, помеченные тегом их статьи. Однако я узнал, что нельзя назначать права доступа на основе тегов.
Затем у меня возникла идея создавать отдельную группу для каждой статьи, где авторы одной статьи будут состоять в одной группе. Но я даже не уверен, решит ли это мою проблему, так как не понимаю, как именно предоставить возможность редактировать определённые сообщения.
Буду признателен, если вы подскажете, существует ли элегантный способ реализовать этот функционал. Спасибо.
Вы хотите, чтобы автор мог редактировать чужие посты, если это ответ на его статью?
И вы имеете в виду посты, а не темы?
Да, в настоящее время определяется тегом, является ли пост ответом или относится к их статье.
Но я также могу создать группу для каждой статьи, если это поможет.
И в идеале должны быть доступны редактирование как постов, так и тем.
Группы очень легковесны: вы можете создавать десятки тысяч без проблем.
С другой стороны, 20 тысяч категорий создадут проблему производительности.
У постов нет тегов, теги есть у тем.
Я не понимаю, зачем вы хотите, чтобы люди могли редактировать чужие посты. Вы можете сделать их вики, но тогда любой сможет их редактировать.
Или, возможно, вы хотите, чтобы тема пользователя была вики, чтобы любой мог её редактировать.
Я просто не понимаю, в какой модели имеет смысл менять чужие слова.
После рассмотрения нескольких сценариев я тоже начал сомневаться в пользе редактирования. Однако было бы здорово иметь механизм, позволяющий увидеть, является ли отвечающий автором статьи, к которой относится тема, и, на мой взгляд, в группах такая возможность до сих пор отсутствует.
Более конкретно: допустим, пользователь создал пост, отметив статью с идентификатором 5. Если автор статьи 5 отвечает на эту тему, идеальная функциональность заключалась бы в том, чтобы как-то указать (например, с помощью значка, заголовка или небольшого текста по умолчанию в верхней части поста), что отвечающий пользователь является автором обсуждаемой статьи.
Если каждая статья — это тема, и вы назначаете автора темы (OP) как автора, то создание правила CSS для визуального отличия ответов от OP в его дальнейших репликах становится тривиальной задачей.
Почему бы не сделать одну тему на статью? Тогда не будет путаницы. Теги или группы не понадобятся.
К тому же, похоже, вы смешиваете понятие «тема» в Discourse (набор сообщений) и «сообщение» (единичное сообщение от одного пользователя, которое находится в теме).
Но @falco опередил меня…
@pfaffman @falco Технически каждая статья — это тег. Причина в том, что одной темы недостаточно для охвата всех обсуждений или вопросов, связанных со статьёй. Существует множество различных аспектов для обсуждения, а главная цель этого форума — создать единый источник всех обсуждений, посвящённых конкретной статье. Следовательно, каждая статья — это тег, и все темы, созданные под тегом статьи, можно просмотреть на странице /tag/:paper_id.
Возможно ли в данном случае применить CSS-трюк? При необходимости я могу создать внешнюю базу данных, определяющую связь между тегами и их соответствующими «авторами-пользователями».
Да, можно создать CSS-файл, который будет автоматически генерироваться на основе анализа указанной базы данных.
Также это можно реализовать полностью в Discourse с помощью кастомного плагина. Это добавит дополнительное поле в сериализатор тем для постов, где автор поста совпадает с определённым условием, что затем можно использовать в фронтенд-приложении.
Понял, я ещё новичок в работе с плагинами, но постараюсь разобраться, что можно сделать. Большое спасибо за совет!
Не стесняйтесь открывать темы в Development, когда застрянете.
Итак, вы понимаете, что теги присваиваются темам, а не постам. Мне кажется, вы используете слово «пост», когда имеете в виду «тему».
Кажется, вы не ответили на этот вопрос. Если вы не хотите, чтобы люди редактировали чужие посты, то у вас, вероятно, нет никаких проблем. Мне трудно представить, зачем кому-то нужно редактировать чужие посты, но если такая потребность есть, решением может стать создание вики.
Отметка тем, посвящённых конкретной статье, тегом этой статьи (по аналогии с DOI, хотя, возможно, на данном этапе жизни статьи DOI ещё не присвоен) — отличная идея, и вы можете реализовать это прямо сейчас с помощью API. Кроме того, пользователи, имеющие право редактировать тему (уровень доверия 3 и владелец темы), могут добавлять тег; остальные могут пометить тему и попросить добавить тег (но разве создатель темы не знает, что она посвящена конкретной статье?).
Мне не совсем понятно, зачем вам сейчас нужен плагин.
Можете рассказать, где именно проявятся проблемы с производительностью? То есть, на конкретных страницах или это общая проблема? Если каждая категория связана с одной-двумя группами, а средний пользователь имеет доступ всего к 10–20 категориям, останется ли проблемой наличие 20 тысяч категорий?
Для моего (гипотетического) сценария это позволит обсуждать публичные темы через личные сообщения групп. Такой подход можно использовать несколькими способами, чтобы стимулировать продуктивные публичные обсуждения по поляризующим темам. По сути, обсуждения можно геймифицировать, предлагая людям вступать в команды (группы), связанные с конкретной темой, и следовать набору правил для ответа на публичную тему в составе команды.
Я готов справиться с проблемами интерфейса, которые создание тысяч групп может вызвать для администраторов сайта. Я понимаю, что это нетипичный сценарий использования групп в Discourse, поэтому публикую это здесь на случай, если я упустил какие-либо очевидные проблемы с производительностью.
Что ж, это звучит более логично, чем я предполагал. 
Думаю, функция создания групп пользователями уже в разработке, но, боюсь, это ещё не скоро.
Это было бы здорово, но пока это можно сделать через API.
Ого. Я начинаю уходить от темы, но можно использовать один из тех API-сервисов, которые получают вебхуки для каждой новой темы и создают для неё группу. Никаких плагинов не требуется. Не знаю, почему я раньше не подумал о том, чтобы использовать Discourse по обе стороны от такого сервиса.
Сегодня мне на глаза попался GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows · GitHub. Похоже, можно заставить его выполнять работу вместо того, чтобы платить за один из таких сервисов. Сомневаюсь, что поддержка Discourse есть из коробки, но заставить его работать должно быть достаточно просто.