Я не спорю. Но когда «конкретные люди» превращаются в группу из нескольких сотен человек, хочется иметь некоторые удобные функции, которые Discourse предоставляет для просмотра публичных тем. Возможно, ключевое отличие здесь — это размер группы получателей?
1 лайк
Привет снова, Джефф! Надеюсь, у тебя всё хорошо.
Я тоже хочу видеть личные сообщения на страницах «Последние», «Лучшие» и «Новые» (по той же самой причине), но отдельно от этого, если я правильно тебя понял, эта часть (переключение статуса существующей темы между публичной и приватной) уже существует.
Через значок гаечного ключа действий администратора на уровне темы в правом верхнем углу можно выбрать «Сделать личным сообщением» (или «Сделать публичной темой», если это уже ЛС). Перевод существующей темы в ЛС, похоже, сохраняет доступ для всех, кто участвовал в обсуждении, а затем можно добавить и группу сотрудников. Правда, при этом тема перемещается из списка тем в раздел сообщений.
Да… отсюда и проблема.
Мне бы очень хотелось что-то вроде скрытой функции, но чтобы сообщение оставалось видимым для всего персонала с определённым уровнем доверия. Возможно, это реализуемо…
Сработает ли ручной настрой, например, trust_level_3, чтобы любой мог отправлять личные сообщения этой группе (через Группы → trust_level_3 → Управление → Взаимодействия)?
Затем, кажется, можно вручную добавить группу trust_level_3 в качестве участника после преобразования публичной темы в личное сообщение.
Возможно, это не совсем то, что вы ищете (и я не уверен, что достаточно хорошо понимаю внутреннее устройство системы, чтобы наверняка сказать, что это сработает), но это может частично решить вашу задачу.
Я тоже присоединился к обсуждению довольно поздно, и мой случай использования практически идентичен случаю @Geoffrey_Challen (ведение большого класса с надеждой использовать Discourse для управления вопросами и ответами, а также обсуждениями).
Лично меня не беспокоит обилие писем (я в любом случае установил режим рассылки), но я считаю, что значительным улучшением качества жизни стала бы возможность из одного места получать ответ на вопрос: «Какие все темы мне, возможно, нужно прочитать или на которые ответить?», независимо от того, были ли эти сообщения публичными или отправленными в группу сотрудников (или, возможно, даже напрямую мне).
Разрешение «создание», обсуждавшееся изначально, было бы одним из способов решения этой задачи. Другим способом могло бы стать отображение личных сообщений (ЛС) определённых групп в виде псевдо-категорий на страницах списка тем (Новые, Топ и т. д.). Учитывая схожесть структуры ЛС и публичных тем в базе данных, это, возможно, было бы реализуемо (хотя, безусловно, это добавило бы определённый уровень сложности).
Другой альтернативой, которая могла бы помочь аналогичным образом, но не потребовала бы таких масштабных изменений, стало бы наличие у поискового поля возможности поиска по всем темам и ЛС одновременно (сейчас, насколько я понимаю, можно искать либо то, либо другое, но не оба сразу), а в идеале — с возможностью уточнения поиска по конкретным группам получателей ЛС. Например, я хотел бы иметь возможность сказать: «Покажи мне все открытые темы, которые были либо публичными темами, либо ЛС, отправленными в группу сотрудников».
Если модификация функции поиска таким образом возможна, это, кажется, обеспечило бы большую часть функциональности, на которую я рассчитывал, и сделала бы это без необходимости вносить изменения, кроме как в поиск. Но, возможно, там тоже есть осложнения, о которых я не подумал.
Я действительно считаю, что это может быть частью проблемы. Возможно, это также связано с объёмом трафика в групповых ЛС по сравнению с публичными сообщениями? Наши случаи использования предполагают большое количество взаимодействий как в публичных темах, так и в групповых ЛС (и большое количество тем в обоих случаях), тогда как для многих других случаев использования личные сообщения сотрудникам могут быть более редкими, и, возможно, это влияет на то, как люди хотят взаимодействовать с этими вещами?
ОК… после нескольких часов работы этим днём я создал прототип разрешения только на создание (в ветке cs125). Протестировано крайне минимально, но вот что, похоже, работает:
- Категории могут быть назначены разрешение на создание.
- Пользователи с этим разрешением могут создавать темы в категории и отвечать на свои собственные темы.
- Они всё ещё могут видеть темы, созданные другими пользователями, но попытка доступа к ним возвращает ошибку «Эта страница приватна или …».
- Администраторы могут видеть и отвечать на все сообщения.
- Я не знаю, продолжают ли работать другие разрешения категорий, но не вижу причин, почему они не должны…
Если это действительно работает, а не просто мои мечты, я бы очень хотел разобраться с пунктом №3, чтобы интерфейс стал менее запутанным для студентов. Но именно здесь я застрял — хотя, возможно, потому что день был довольно длинным. @sam: нужна ли тут помощь, или вы откажетесь от нас, раз мы так далеко ушли от нормы 
. По сути, я хочу иметь возможность фильтровать список тем в категории (и вообще все списки тем), исключая темы из категорий, где у пользователя есть только разрешение на создание, если только пользователь не создал эту тему.
PS: эта ветка также расширяет права на «шёпот» для пользователей с уровнем доверия >= 3. Другим это изменение может понадобиться или нет, но для нас оно полезно, так как права модератора — это слишком много возможностей для большинства моих преподавателей курса, а «шёпот» очень удобен при совместной работе над помощью студентам.
@sam: ещё один быстрый вопрос. Есть ли хоть какой-то шанс сделать любое из этих действий через плагин?
Это почти в точности то, как работает плагин «Restricted Replies».
Единственное, что он не обрабатывает, — это пункт (3). Это будет крайне сложно реализовать по всем причинам, перечисленным выше.
3 лайка
Поправьте меня, если я ошибаюсь, но похоже, что ваш плагин не предотвращает возможность просмотра постов, которые пользователи не создавали. Для нашего сценария это критически важно: студенты публикуют вопросы на нашем учебном форуме, которые могут содержать код или другие части их решений. Поэтому нам нужно не только то, чтобы отвечать могли только сотрудники, но и то, чтобы видеть посты могли только они. Плагин Restricted Replies заявляет, что он работает как разрешение «Создать / Ответить (себе) / Просмотреть». Нам же нужно фактически «Создать / Ответить (себе)», но без возможности просмотра.
Тем не менее, очень обнадеживает то, что это можно реализовать через плагин. Не могли бы вы также добавить ограничение на просмотр, чтобы поддержать наш сценарий?
Касательно пункта #3: я задумывался, не проще ли было бы реализовать это на стороне клиента. В настоящее время благодаря нашим изменениям студенты не могут даже заходить в эти темы, поэтому, если бы мы могли просто скрывать их в интерфейсе, этого было бы достаточно.
Да, вы правы. Именно поэтому я сказал, что это не решает задачу (3).
А что, если пользователь подписан на категорию и получает уведомления по секретной теме? Как насчет режима рассылки? А страницы «активность» пользователя? Топ-тем? Новых тем? Поиск? И, вероятно, множество других вопросов… Это масштабная задача, и я бы не рекомендовал её реализовывать.
Групповые личные сообщения созданы именно для вашего случая использования. Мы обрабатываем всю нашу поддержку по электронной почте через групповые личные сообщения здесь, на Meta, и это работает отлично! Если у вас есть конкретные проблемы с удобством использования групповых почтовых ящиков, то, на мой взгляд, ваше время будет лучше потрачено на поиск улучшений именно в этой области.
3 лайка
Я не спорю. Но мы здесь, потому что попробовали групповые личные сообщения, и они работают не очень хорошо, учитывая, что сообщение получают около 200 человек.
Я уже касался этого в своём ответе Сэму, но групповые сообщения, похоже, не работают эффективно, когда список получателей становится действительно большим, и вероятность того, что я отвечу каждому индивидуально, снижается. Другими словами: если бы групповые сообщения работали так хорошо, люди всё ещё использовали бы большие открытые списки рассылки, а не такие отличные инструменты, как Discourse.
Вероятно, мы продолжим использовать групповые сообщения, чтобы не рисковать сбоями, на которые вы, кстати, справедливо указали, которые могут возникнуть при попытке изменить права доступа к категории. Но не очень полезно слышать «групповые сообщения работают отлично!», когда ваш опыт показывает, что на самом деле они работают далеко не отлично 
2 лайка
Конечно, всегда будут различия в том, как вещи используются в разных сообществах. Я имел в виду, что было бы интересно исследовать, какие доработки потребуются, чтобы вы могли успешно использовать личные сообщения (ЛС). Я считаю, что внесение изменений здесь гораздо более достижимо, чем повторная реализация функций ЛС в обычных категориях.
Какие именно проблемы вы наблюдаете с групповыми ЛС? Для примера, возможно, это перегрузка уведомлениями? Это была одна из проблем, с которыми мы столкнулись изначально, и теперь вы можете настроить уровень отслеживания для каждого группового ящика.
6 лайков
Да, это было очень полезное дополнение! Спасибо.
Если вы ознакомитесь с некоторыми обсуждениями выше, то, думаю, увидите несколько проблем с системой личных сообщений. В основном, это связано с тем, что для работы с сообщениями предусмотрен иной рабочий процесс, что создаёт искусственное разделение между темами, которые я хотел бы обрабатывать аналогичным образом. (Отсюда и попытка интегрировать это в существующую модель разрешений категорий.)
Здесь есть список, но всё сводится к тому, чтобы сделать группы сообщений максимально похожими на категории. Размещение их на главной странице и в просмотре последних тем, одинаковый внешний вид при просмотре, единые возможности поиска и фильтрации (без необходимости помнить, что это сообщение) и т. д. К сожалению, я чувствую, что это потребует столько же, если не больше, изменений, чем дополнительные разрешения для категорий. Но, возможно, нет?
@david: Извините, что вмешиваюсь в разговор, но у меня очень похожий случай использования, как и у @Geoffrey_Challen. И хотя я, конечно, не могу говорить за него, я думаю, что одной конкретной вещью, которая помогла бы именно мне в этом плане, была бы возможность запускать один поисковый запрос так, чтобы он находил и публичные темы, и личные сообщения (сейчас, похоже, я могу искать либо публичные темы, либо личные сообщения, но не оба сразу, если только я что-то не упускаю).
Я понимаю, что некоторые из других предложенных здесь изменений (разрешение «Создать», возможность отображения личных сообщений в обычных списках тем и т. д.) требуют масштабных и сложных правок, но, возможно, изменение поиска, позволяющее искать по всем темам (публичным и личным), было бы более практичным и локальным решением, при этом всё ещё предоставляя возможность получить некоторое подобие единого представления обо всём этом через поиск.
Для меня я не считаю, что переопределение интерфейса по умолчанию важно, но было бы фантастически, если бы у меня был какой-то способ быстро ответить на вопрос: «Какие все темы мне сейчас, возможно, нужно обработать?», независимо от того, публичные они или личные, и уточнять этот список по тегам и т. п.
Тем временем я написал небольшой скрипт, который позволяет получить такой унифицированный список напрямую из базы данных Postgres, или же я могу запускать два отдельных запроса через диалог поиска для каждой категории (один для публичных и один для личных), но оба эти варианта довольно утомительны…
2 лайка
Мне кажется, это отличная идея — я бы этим воспользовался. Лучше всего создать новую тему с тегом #feature, чтобы не потерять эту идею в рамках текущей темы.
Редактирование: готово здесь
4 лайка
Мне действительно сложно понять нежелание разрешать такую структуру прав доступа, хотя эта тема обсуждается с 2015 года. Я вполне понимаю привлекательность идеи автора оригинального поста, а также опасения по поводу использования личных сообщений в качестве альтернативы. Более детальная настройка прав доступа стала бы настоящим прорывом для Discourse — это открыло бы множество возможностей для более творческого использования платформы в сообществах.
Последствия гранулярных разрешений… хорошо документированы. У меня до сих пор кошмары от того, какой беспорядок в правах доступа к категориям устроил vBulletin, именно по этой причине.
Суть в том, что если вы хотите, чтобы пользователи могли создавать темы и видеть только те темы, которые они создали, то такая функциональность уже существует в личных сообщениях. В сочетании с групповыми почтовыми ящиками это уже воспроизводит желаемое поведение.
1 лайк
Лично у меня нет опыта работы с vbulletin или другим форумным ПО. Мой опыт работы с платформами, основанными на сообществах, связан с Discord, где создатели сообществ имеют больше контроля над правами доступа. Я также видел, как системы прав доступа успешно реализованы во многих других системах, обеспечивающих более гибкое управление. Я не думаю, что кто-то просит здесь 500 переключателей, а скорее возможность независимо назначать права на создание, просмотр и ответы.
Желаемое поведение заключается в том, чтобы пользователь открывал категорию, нажимал «Новая тема», вводил свой контент, и его пост был виден только ему и тем, у кого есть право «просмотр». Личные сообщения гораздо менее удобны для навигации пользователем, чем то, что я описал выше — они требуют больше инициативы от пользователя, а функция более скрыта в интерфейсе.
Более простое решение проблемы — возможность создания тем по электронной почте, однако у этого подхода тоже есть недостаток. Он не способствует прямому участию в жизни сообщества и требует от пользователя использования сторонней системы для достижения цели.
Личные сообщения и права доступа к категориям — это две разные темы, и они не совсем соответствуют тому, что просил автор оригинального поста, и не являются тем, что будут искать многие пользователи, которые придут позже.