Плагин Discourse Staff Alias позволяет определённым группам создавать темы и сообщения, а также вносить правки от имени пользователя-алиаса. Это может быть полезно в ситуациях, когда сотрудникам необходимо отвечать на запросы или делать объявления, не раскрывая свои личные имена пользователей.
Включение Staff Alias
После установки плагин Staff Alias можно включить в его настройках, доступ к которым осуществляется со страницы admin/plugins:
Этот плагин по умолчанию отключён. Перед включением необходимо добавить новое имя пользователя для алиаса в настройку администратора staff alias username:
После включения плагина будет создан пользователь с указанным именем.
Использование алиаса
После включения алиас Staff Alias можно активировать через выпадающее меню действий в редакторе сообщений. Пользователи из разрешённых групп смогут затем создавать темы и сообщения, а также вносить правки от имени алиаса Staff:
Также я не могу назначить существующего пользователя псевдонимом сотрудника, даже после повторной проверки, что, если подумать, вполне логично. Не уверен, что заставило меня поверить в возможность этого. Обновлю инструкцию.
Спасибо! Жаль, потому что, на мой взгляд, это обеспечивает единообразие, когда все сотрудники могут использовать название сайта или, например, уже существующую «главную» учётную запись. Например, @Discourse.
Невозможно ответить на сообщение в ответ пользователю с опцией псевдонима сотрудника — я получаю ту же ошибку, что и выше. Однако, если использовать псевдоним сотрудника для ответа на тему сообщения, всё работает корректно.
Каковы шансы, что это можно будет расширить до динамического инструмента «публикация от имени другого пользователя»?
У нас есть сценарий использования, когда менеджер по коммуникациям продукта должен создавать новые темы от имени других менеджеров продукта в нашей организации. Похоже, что в этом инструменте уже есть большая часть необходимой функциональности, но потребуется возможность динамически указывать пользователя, от имени которого будет опубликован пост.
Если твой продакт-менеджер является модератором всего сайта, он может использовать гаечный ключ на сообщении, чтобы «сменить владельца». Плагины не требуются.
Хотел отметить, что я потратил довольно много времени, пытаясь понять, почему на сайте был создан неизвестный модератор.
У этого пользователя был случайный хэш в качестве адреса электронной почты, что выглядело довольно подозрительно.
Думаю, было бы полезно оставить заметку для персонала, зафиксировать действие «Назначение модератора» в журнале действий персонала или каким-либо другим образом указать, что этот пользователь был создан плагином
Я пробую это использовать и задаюсь вопросом: какое ожидается поведение в отношении уведомлений и писем для пользователя staff_alias?
У пользователя staff_alias вместо адреса электронной почты указан случайный набор символов, поэтому письма, которые обычно отправляются, пропускаются.
Я не могу указать для псевдонима сотрудника реальный адрес электронной почты, так как Discourse пытается отправить письмо с подтверждением на случайный набор символов.
Является ли staff_alias односторонним каналом? Возможно, я что-то упускаю. Есть ли (или должно ли быть) решение, позволяющее использовать его как «фасад» для реальной учётной записи, например admin, которая получает сообщения как обычно?
При управлении крупными сообществами вопросы идентификации могут быть довольно сложными. Когда вы разрешаете многим сотрудникам публиковать сообщения от имени «алиаса сотрудника», фактическая учётная запись модератора, использовавшая этот алиас для публикации, также отображается для других сотрудников, как показано на скриншоте.
Если за алиасом сотрудника стоит «реальная учётная запись», то открывается множество других опций для пользователей, что затрудняет отслеживание того, какие именно сотрудники внесли изменения в учётную запись.
Какого рода «сообщения» вы ожидаете получать? Мне кажется, что есть другой способ достичь вашей цели.
Спасибо за ответ, @nat. Я просто подумал, что если я опубликую сообщение с staff_alias, пользователи могут отреагировать, и я не хочу упустить их ответы.
Я опасался, что никто не увидит такие уведомления, но позже выяснил, что получаю эти письма и уведомления на аккаунт сотрудника, который использовал псевдоним. Так что это здорово.
Несколько оставшихся вопросов:
В журнале пропущенных писем указаны ошибки при попытке отправки на строку staff_alias. Предполагаю, что я могу отключить все настройки почты для staff_alias, и письма всё равно будут генерироваться и отправляться на «родительский» аккаунт сотрудника..?
Я могу видеть личные сообщения, отправленные на staff_alias, только зайдя в его профиль через панель администратора. Возможно, имеет смысл просто отключить возможность отправки личных сообщений на staff_alias?
Буду благодарен за любые советы.
После дополнительных экспериментов я чувствую, что лучше понимаю ситуацию… но в теме плагина было бы полезно добавить информацию о маршрутизации уведомлений и некоторые рекомендации по другим соответствующим настройкам аккаунта.
Привет, @nat — похоже, плагины действительно нуждается в некоторой доработке:
a.) Я пробовал отключить электронную почту для staff_alias, и это превращается в своего рода «чёрную дыру». Письма и уведомления на «родительскую» учётную запись не отправляются. Поэтому я пока снова включу электронную почту и буду игнорировать уведомления о пропущенных письмах.
b.) Отключение личных сообщений для staff_alias не мешает привилегированным аккаунтам, таким как администраторы и модераторы, писать ему — и такие сообщения видны только при целенаправленном поиске. Возможно, их тоже можно перенаправлять на соответствующий «родительский» аккаунт?
Пока эти моменты не вызывают у меня серьёзных опасений, но я могу представить проблемы для сайтов с большим количеством сотрудников и высокой активностью. Буду следить за новостями… спасибо!
Размещено нами? Этот плагин доступен в нашем тарифном плане Enterprise.
Обновлю инструкцию. 
