Это ли сценарий использования для пользовательских полей?

Я пытаюсь разобраться, как разрешить пользователям создавать подфорумы, которые работали бы как каналы Slack.

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

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

Можно ли использовать «пользовательские поля» для достижения этого? Например, как-то пометить пользователя как имеющего право публиковать сообщения с определённым тегом?

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

Полагаю, теги не имеют никаких разрешений на уровне пользователей. Возможно, вам стоит проверить категории.

Discourse использует группы и категории для контроля доступа к контенту. Посмотрите видео в этой теме для подробностей: Как использовать настройки безопасности категорий для создания приватных категорий

Спасибо за ответы, ребята. Я согласен, что категории кажутся более простым решением. Однако это будут подразделы, которые пользователи смогут создавать в большом количестве. Их может быть сотни или даже больше (подразделы являются ключевой частью приложения, поэтому их количество будет расти вместе с ростом базы пользователей).

Мне сказали, что создание сотен или тысяч категорий создаст большие проблемы, поэтому мне стоит поискать другие решения. Есть ли у вас другие предложения? Я готов разработать отдельное приложение, которое будет взаимодействовать с API. Главное, что мне нужно от Discourse, — это превосходный функционал постов, ответов и тегов.

То, что вы хотите создать, не является целью проекта Discourse.

Вам нужна платформа, похожая на Reddit или Discord, где пользователи могут создавать сабреддиты или серверы, которыми они «владеют», при этом вы сохраняете полный контроль и монетизацию всей платформы.

Discourse ориентирован на противоположное: каждый сабреддит, сервер или гильдия становится отдельным сайтом, владеет своими данными и существует на своём собственном URL-адресе.

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

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

Discord не подойдёт для этих целей из-за ограничений, которые они накладывают на интеграцию с приложениями. Я не знаком с тем, как можно интегрировать Reddit с приложением.

Вы предлагаете, что я могу реально реализовать это с помощью Reddit, или вы просто имели в виду, что это тот «тип» функциональности, который я имею в виду?

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

Эта ключевая функция не входит в план разработки, и мы не планируем её добавлять.

За эти годы было много тем на эту тему:

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

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

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

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

Я ценю все ваши ответы. Не мог бы кто-нибудь привести примеры того, как обычно используются пользовательские поля?

Кажется, я мог бы просто добавить пользовательское поле, связанное с конкретным подразделом (например, ‘subforum123’), к каждому разрешённому пользователю, а затем, когда пользователь заходит на страницу подраздела, обращаться к API, чтобы проверить, есть ли у пользователя необходимое пользовательское поле. Если да, то он может там публиковать. Если нет, то не может, и, возможно, я просто скрою кнопки «Новая тема» и «Ответить».

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

Возможно, то, что вы хотите сделать, — это позволить пользователям создавать свои собственные форумы Discourse (например, username.yoursite.com), которые будут работать на многосайтовой установке, где ваш «основной» форум Discourse выступает в роли SSO-сервера для подсайтов пользователей. Теоретически можно создать плагин, который будет создавать новый сайт Discourse с адресом username.yoursite.com при регистрации нового пользователя. Но, возможно, не каждый пользователь захочет иметь собственный подфорум, и вместо этого вы могли бы реализовать . . . что-то . . . что позволяло бы им создавать свои подсайты.

Кажется, это уже близко к тому, что вы пытаетесь сделать.

Это действительно приближается к тому, что я имею в виду («подфорумы» были целью). Спасибо. Я подробнее изучу мультисайтовость.

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

Это так, но у этого подхода есть преимущество — он возможен.

Да, мне известно как минимум об одной компании, у которой есть сотни и более подсайтов, использующих как минимум два разных набора плагинов, с затратами от 100 до 300 долларов в месяц. Другие берут 20 долларов в месяц за каждый сайт.

На всякий случай, если это не очевидно: по сути, вы строите компанию по хостингу Discourse.

Для начала вам потребуется от 4 до 16 ГБ оперативной памяти, например, для нескольких десятков сайтов.

Подтвердите, пожалуйста, правильно ли я понял, что эта компания платит $100–$300 в месяц за поддержку сотен подсайтов? (Кажется, именно это вы и имеете в виду — это довольно небольшая сумма для такого количества подсайтов).

Я имею в виду, что одна компания (та, которая разрабатывает Discourse) взимает 100–300 долларов за сайт, который вы планируете создать. Некоторые другие берут порядка 20 долларов в месяц; по-видимому, они успешно зарабатывают на этом.

На решение проблемы, которую я предложил, вероятно, уйдёт как минимум сто часов, а скорее всего — ещё больше.

РЕДАКТИРОВАНИЕ: Но, возможно, если вам нужен всего один мультисайт, вы сможете запустить его быстрее.

Хорошо. Понял. Спасибо за информацию.