Discourse Staff Alias 插件允许特定组以别名用户身份创建主题和帖子，以及进行编辑。这在员工需要回应查询或发布公告而无需透露其个人用户名的情况下非常有用。
启用员工别名
安装后，可以从 admin/plugins 页面访问其设置来启用 Staff Alias 插件：
该插件默认禁用，在启用之前，必须将新的别名用户名添加到“员工别名用户名”管理员设置中：
启用插件后，将创建具有该用户名的用户。
使用别名
启用后，可以通过作曲器操作下拉菜单切换员工别名，允许组中的用户选择使用员工别名创建主题和帖子，以及进行编辑：
主题/帖子/编辑将显示为仿佛由员工别名创建：
跟踪谁使用了别名
如果您属于允许组之一，您还将看到谁创建了主题或帖子，或进行了编辑的记录：
设置
| 名称 |
描述 |
| staff alias enabled |
启用 discourse-staff-alias 插件 |
| staff alias username |
别名用户的用户名 |
| staff alias allowed groups |
允许以员工别名用户身份发帖的组 |
由我们托管？此插件可在我们的企业版中获取。
41 个赞
我可能在编写说明时犯了一个错误。 
我也无法让现有用户成为 staff alias，在我再次测试时是这样的，仔细想想也说得通。我不确定是什么让我认为这是可能的。 
我会更新说明。 
4 个赞
sok777
(sok)
19
谢谢！这很可惜，因为我认为当所有员工都能使用网站名称或像一个已存在的“主”账户时，它会变得统一。例如 @Discourse
4 个赞
您的 staff 别名用户是否有权限在该类别中创建主题？（他们是否拥有 staff 权限）
1 个赞
barto_95
(🇵🇹 | )
23
当使用 staff alias 回复用户消息时，无法进行回复，并收到上述错误，但如果使用 staff alias 回复消息主题，则可以正常进行。
这个工具被扩展为动态“以其他用户身份发帖”的可能性有多大？
我们有一个用例，其中产品沟通经理需要以我们组织内其他产品经理的身份创建新主题。该工具似乎已经具备了大部分功能，但需要能够动态设置发帖用户。
4 个赞
fokx
25
每次回复非 OP 的帖子时，我都会遇到同样的错误：
发生错误：您无权查看请求的资源。
经过一番研究，我发现罪魁祸首在于：
问题是：
params[:whisper] 是 "false"，这是一个字符串，所以只需将此行更改为：
if !DiscourseStaffAlias.user_allowed?(existing_user) || params[:whisper] == "true"
…就能解决问题。
我做了一个简单的 PR：FIX: InvalidAccess when replying to non-original post by fokx · Pull Request #67 · discourse/discourse-staff-alias · GitHub
5 个赞
Heliosurge
(Dan DeMontmorency)
26
嗨 Jordan，
我想了几个选项。
如果你的产品经理是网站版主，他们可以使用帖子上的扳手图标来“更改所有权”，无需插件。
1 个赞
Bas
(Bas van Leeuwen (OOO until April 14))
27
我想指出，我花了相当长的时间才弄清楚为什么一个网站上会创建一个神秘版主。
该用户的电子邮件是一个随机的哈希值，看起来相当可疑。
我认为最好留下一个工作人员备注，在工作人员日志中记录“授予版主权限”，或者给出其他一些指示，表明该用户是由插件创建的:)
2 个赞
Heliosurge
(Dan DeMontmorency)
28
如果您的自托管或计划支持。Plugin 用户笔记非常方便
1 个赞
ToddZ
29
我正在尝试这个，想知道：对于 staff_alias 用户，预期的通知和电子邮件行为是什么？
staff_alias 用户会收到一个随机字符串作为电子邮件地址，因此通常会发送的电子邮件会被跳过。
我无法为 staff alias 提供真实的电子邮件地址，因为 Discourse 会尝试向该随机字符串发送确认电子邮件。
staff_alias 是单行道吗？也许我遗漏了什么。是否有办法让它像 admin 一样充当真实帐户的“前端”，从而像往常一样接收通信？
1 个赞
nat
(Natalie T)
30
是的。
在管理大型社区时，身份可能会非常棘手。当您允许许多“员工”以“员工别名”的身份发帖时，实际使用员工别名发帖的版主帐户也会显示给员工，如下图所示
如果您在员工别名背后放置一个“真实帐户”，那么将暴露许多其他用户选项，这使得很难审核是哪个员工对帐户进行了哪些更改。
您期望收到什么样的“沟通”？我觉得有另一种方法可以实现您希望达到的目标。
2 个赞
ToddZ
31
感谢您的回复，@nat。我只是认为，如果我使用 staff_alias 发帖，用户可能会回复，而我不想忽略他们。
我曾担心没有人会看到此类通知——但此后我发现，我确实会收到发送到使用该别名的“父级”员工账户的电子邮件和通知。所以，这很棒。
还有几个遗留问题：
感谢您的任何建议。
经过更多实验，我感觉对事情的理解更近了一步……但插件主题可以提及通知的路由方式，并提供有关其他相关账户设置的指导。
3 个赞
nat
(Natalie T)
32
啊，这应该在插件本身中得到处理。这是我们在构建它时考虑不周的地方，所以我们应该修复它。
这作为默认设置是有意义的。让我与我的产品团队核实一下。
2 个赞
ToddZ
37
你好 @nat – 插件似乎确实需要一些微调：
a.) 我尝试关闭 staff_alias 的电子邮件，它变成了一个黑洞。发送到“父”帐户的电子邮件和通知不会被触发。所以我会重新启用电子邮件，暂时忽略跳过的电子邮件通知。
b.) 禁用发送到 staff_alias 的私人消息并不能阻止管理员和版主等特权帐户向其发送消息——这些消息只有在查找时才能看到。也许也可以将这些消息路由到相关的“父”帐户？
这些对我来说还不是大问题，但我可以想象对于拥有更多员工和更繁忙活动的网站来说会存在问题。我会关注任何消息……谢谢！
2 个赞
ToddZ
38
我也遇到了同样的问题。看起来那个 PR 还在等待审查……
