Специфические шёпоты для групп в дополнение к персоналу

Продолжение обсуждения из Как создать пост-шёпот?:

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

Пример:
У нас есть @documentation-group, который мог бы использовать шёпоты без необходимости доступа к шёпотам сотрудников.

Было бы полезно иметь возможность опционально разрешить более одного раздела шёпотов. В любом случае спасибо за рассмотрение.

3 лайка

Я считаю, что групповой доступ к шепотам был добавлен недавно:

Но тогда все группы могли бы видеть все шепоты. Мне кажется, что изолированные шепоты были бы хорошим дополнением, хотя я не знаю, насколько сложно их реализовать. :slight_smile:

7 лайков

Неужели за два прошедших года этот вопрос не возникал в вашей команде? :smiley:

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

1 лайк

Боюсь, что когда я поднял этот вопрос, его признали «ОченьСложным™», и до сих пор он не вызвал особого интереса.

1 лайк

Это предложение по функционалу может быть интересно как альтернатива

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

  • Административные приватные сообщения: видеть может только администратор
  • Приватные сообщения внутренней команды: видеть может также администратор
  • Внешние пользователи: не могут видеть никакие приватные сообщения
1 лайк

Если плагин BBCode или компонент темы не должен влиять на личные сообщения.

По ссылке, которую я предоставил, у вас будет дополнительный код в сообщении, позволяющий показывать часть сообщения всем, а скрытый контент — только автору темы и целевой группе.

Однако сейчас обычные пользователи не могут просматривать ревизии сообщений, кроме сотрудников.

Идея решения на основе BBCode позволила бы скрывать часть сообщения от определённой группы. Один из примеров — настольные ролевые игры. Однако опытные пользователи могли бы просмотреть скрытый контент через «Инструменты разработчика» и изменить CSS.

Я считаю, что запрос на #функцию довольно понятен, и нам стоит быть осторожными, чтобы не воспринимать всё как тему #поддержки и не углубляться в обходные пути. Давайте постараемся сохранить фокус. :+1:

2 лайка

Вы представляете, что внутренняя команда A может видеть шёпот команды B?

Или что каждая внутренняя команда может видеть только шёпот своей команды?

Или что для каждого шёпота каким-то образом нужно определять получателей?

В каком случае вы выберете использование шёпота вместо личного сообщения для управления получателями?

(Отвечаю как коллега @putty)

В идеале — второй вариант, но я понимаю, что группировка разных пользователей в различные группы может быть довольно сложной. Суть в том, что у нас в компании много внутренних команд, которые теперь тоже хотят создавать опыт для своих пользователей на нашем Discourse. Чувствуется, будто мы построили родительское сообщество, а они создают внутри него мини-сообщества.

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

1 лайк

Хорошо, я вас услышал.

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

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

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

  • В категории A группы X и Y могут видеть шёпоты
  • В категории B группа Z может видеть шёпоты

В такой модели X и Y всё ещё смогут видеть шёпоты администраторов в категории A. Но я думаю, что можно определить категории и нормы таким образом, чтобы это работало, не добавляя третий уровень шёпота в рамках одной темы.

2 лайка

Что вы думаете о такой идее:

  • административные шёпоты
  • шёпоты

как описал @putty. Это был бы отличный компромисс, потому что, по крайней мере в нашем случае, все участники раздела «все остальные шёпоты» являются сотрудниками одной компании. Я делаю предположение, но чувствую, что с каждым днём всё лучше понимаю сложности платформы: я полагаю, что при такой конфигурации это было бы (хотя бы отчасти) менее сложно, чем предоставление отдельным группам возможности контролировать, кто может видеть их шёпоты?

Это дало бы сотрудникам всей компании возможность шептаться в сообществе друг с другом независимо от категории, темы или личных сообщений. Теперь, когда я об этом подумал, это звучит просто потрясающе. Это было бы невероятно!

1 лайк

Да, я не уверен, что в итоге будет сложнее реализовать и настроить. Меня всё ещё беспокоит наличие третьего уровня обсуждений в рамках одной темы.

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

Стоит ли рассмотреть возможность принятия такого ограничения?

В каких сценариях вам понадобится, чтобы администратор мог писать в личные сообщения, и это не было бы видно всем сотрудникам? И разве вы не хотели бы хотя бы иногда, чтобы администраторы могли писать в личные сообщения другим сотрудникам, если вы разрешаете остальным сотрудникам переписываться друг с другом? Как это будет работать?

Возможно, в модели «все сотрудники могут писать друг другу в личные сообщения» администраторам следует использовать другой инструмент для приватного общения между собой (например, личные сообщения, категорию только для персонала или чат-канал). Если это приемлемо, вы можете реализовать это уже сегодня.

3 лайка

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

Да!

  • Сотрудники могут видеть/отвечать/создавать приватные переписки для сотрудников
  • Сотрудники могут видеть/отвечать/создавать обычные приватные переписки
  • Сотрудники могут видеть/отвечать/создавать обычные приватные переписки
  • Сотрудники не могут видеть/отвечать/создавать приватные переписки для сотрудников

Например, сотрудники увидят следующее:

а обычные сотрудники увидят это:

Это просто какие-то «фрэнкенштейновские» скриншоты, но, думаю, это передаёт суть.

4 лайка

Да, думаю, это передаёт суть.

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

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

2 лайка

Принять решение сейчас непросто. Философия, которой я всегда руководствуюсь в работе с командой, — делать то, что лучше для наших пользователей, а не то, что проще для нас, потому что в конечном итоге это будет лучше и для нас.

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

2 лайка

+1 за эту функцию! :slight_smile:

В нашем случае у нас есть команда авторов и других участников, не являющихся модераторами, и я хотел бы предоставить им возможность использовать шепот в определённых категориях, не делая при этом видными для них служебные/модераторские шепоты.

3 лайка

Это не было бы безопасно. И хитрые пользователи могли бы это обойти.

Но как насчет компонента темы, который использует CSS, чтобы скрывать (display: none) шепот, созданный персоналом, если текущий пользователь не является сотрудником? Что касается определенных категорий.

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

Группе «Персонал» нужно было бы знать, не распространять вещи, имеющие реальную чувствительность или требующие мер безопасности.

Что-то подобное можно было бы использовать как временное решение с оговорками.

Хм … как именно?

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

«Секретные сообщения не для админов» не будут включены в сериализованные данные для тех, кто не имеет к ним доступа.

Если существуют какие-либо препятствия для реализации этого, я не думаю, что это одно из них.

2 лайка

Я просто использовал простой CSS в компоненте темы.

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

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

Я основывал свой вывод на идее из другой темы: использовать общий CSS для bbcode, чтобы скрывать контент в сообщении и показывать его только определённому пользователю или группе.

1 лайк