В нашей компании мы активно используем «шёпот» для внутренней коммуникации по различным темам.
Почти каждая роль в нашей организации (продажи, услуги, разработчики, менеджеры проектов, управление сообществом, UX, документация) играет важную роль в нашем пользовательском сообществе. Для нас это означает, что каждый сотрудник должен иметь возможность просматривать «шёпот».
В Discourse для просмотра «шёпота» необходимо состоять в группе staff. В нашем случае это означает предоставление прав модератора более чем 300 людям. Это пользователи, которые в противном случае отлично справились бы с уровнем TL4.
Кратко: всем нашим сотрудникам нужно видеть «шёпот», но лишь немногим требуются права модератора.
Мы считаем, что было бы очень полезно, если бы:
Появилась настройка, позволяющая пользователям TL4 видеть «шёпот», или…
Стало возможным указывать группы, которые должны иметь доступ к «шёпоту», вместо того чтобы разрешать это только группе staff
Была предложена какая-то лучшая альтернатива, о которой мы ещё не подумали
Очень интересная проблема, я вас прекрасно понимаю и согласен, что это разрешение должно основываться на группах.
К сожалению, это серьёзное изменение из-за того, как мы спроектировали многие внутренние компоненты.
На первый взгляд может показаться, что это простое изменение… достаточно переписать эти два метода:
Но изменения во внутренних механизмах Discourse затрагивают гораздо более глубокие слои.
У нас даже есть столбец, отслеживающий highest_post_number_including_whispers… но он называется highest_staff_post_number.
Другая сложность заключается в том, что нам потребуется проверка группы, чтобы определить, может ли пользователь видеть шёпот, а сейчас проверка дешевле, так как мы просто обращаемся к записи пользователя.
Я сохраняю это для внутреннего обсуждения и посмотрю, сможем ли мы что-то сделать, но, к сожалению, сложность здесь довольно высока.
Может быть, стоит рассмотреть другой подход — ввести новый уровень членства в команде?
Администратор > Модератор > Команда
Они всё ещё могли бы считаться «сотрудниками», но не отображаться на странице «О нас».
У меня уже были случаи, когда было удобно иметь возможность отмечать других сотрудников в обсуждениях, даже если они не следят за большинством активностей в сообществе (например, передать продукт-команде для получения соответствующей обратной связи), но при этом не хотелось наделять их правами модераторов.
Я вас понимаю, но наша общая стратегия заключается в переходе к гибким разрешениям на основе групп. Мы уже внедрили это для назначенных и решённых задач и будем расширять эту функциональность на всё больше разделов.
Я придумал обходной путь: использовать функцию чата по теме, предоставить доступ к этому каналу только сотрудникам и вашей командной группе и использовать его для личных сообщений вместо реальной функции приватных сообщений.
В последнюю версию Discourse добавлена новая функция, позволяющая указывать дополнительные группы, чьи члены смогут просматривать и создавать секретные сообщения.
@Colin_Mueller Изменения уже должны быть применены на вашем сайте
Спасибо за предложение, это действительно то, чего многие хотели. Здесь прослеживается повторяющаяся закономерность: использование TL или Staff в качестве ограничителя оказывается гораздо менее гибким, чем предоставление разрешений на основе групп.
