The Discourse Staff Alias plugin allows certain groups to create topics and posts, as well as make edits, as an alias user. This can be useful in situations where staff members need to respond to queries or make announcements without revealing their personal usernames.
Once installed, the Staff Alias plugin can be enabled from its settings, accessed from your admin/plugins page:
This plugin is default disabled, and before enabling a new username for the alias must be added to the staff alias username admin setting:
Once the plugin is enabled, a user with that username will be created.
Once enabled, the staff alias can be toggled on using the composer’s actions drop-down, and users in the allowed groups can then choose to create topics and posts, as well as make edits, using the staff alias:
The topic/post/edit will then appear as if created by the staff alias:
If you are in one of the allowed groups you will also see a note of who created the topic or post, or made the edit:
Name
Description
staff alias enabled
Enable discourse-staff-alias plugin
staff alias username
Username of the alias user
staff alias allowed groups
Groups that are allowed to post as staff alias user
Last edited by @Bas 2024-08-12T14:12:55Z
Check document Perform check on document:
41 个赞
我可能在编写说明时犯了一个错误。
我也无法让现有用户成为 staff alias，在我再次测试时是这样的，仔细想想也说得通。我不确定是什么让我认为这是可能的。
4 个赞
sok777
2023 年9 月 12 日 11:40
19
谢谢！这很可惜，因为我认为当所有员工都能使用网站名称或像一个已存在的“主”账户时，它会变得统一。例如 @Discourse
4 个赞
您的 staff 别名用户是否有权限在该类别中创建主题？（他们是否拥有 staff 权限）
1 个赞
barto_95
2024 年1 月 22 日 13:17
23
当使用 staff alias 回复用户消息时，无法进行回复，并收到上述错误，但如果使用 staff alias 回复消息主题，则可以正常进行。
这个工具被扩展为动态“以其他用户身份发帖”的可能性有多大？
我们有一个用例，其中产品沟通经理需要以我们组织内其他产品经理的身份创建新主题。该工具似乎已经具备了大部分功能，但需要能够动态设置发帖用户。
4 个赞
fokx
2024 年5 月 24 日 09:06
25
每次回复非 OP 的帖子时，我都会遇到同样的错误：
发生错误：您无权查看请求的资源。
经过一番研究，我发现罪魁祸首在于：
prepended do
include WithCurrentUser
around_action do |controller, action|
if DiscourseStaffAlias::CONTROLLER_ACTIONS.include?(action_name = controller.action_name) &&
(params = controller.params).dig(
*DiscourseStaffAlias::CONTROLLER_PARAMS[action_name],
) == "true"
existing_user = controller.current_user
if !DiscourseStaffAlias.user_allowed?(existing_user) || params[:whisper]
raise Discourse::InvalidAccess
end
alias_user = DiscourseStaffAlias.alias_user
alias_user.aliased_user = existing_user
controller.with_current_user(alias_user) { action.call }
else
action.call
end
问题是：
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
2024 年8 月 1 日 16:10
26
嗨 Jordan，
我想了几个选项。
如果你的产品经理是网站版主，他们可以使用帖子上的扳手图标来“更改所有权”，无需插件。
1 个赞
Bas
2024 年8 月 12 日 14:15
27
我想指出，我花了相当长的时间才弄清楚为什么一个网站上会创建一个神秘版主。
该用户的电子邮件是一个随机的哈希值，看起来相当可疑。
我认为最好留下一个工作人员备注，在工作人员日志中记录“授予版主权限”，或者给出其他一些指示，表明该用户是由插件创建的:)
2 个赞
Heliosurge
2024 年8 月 14 日 03:13
28
如果您的自托管或计划支持。Plugin
[/admin/plugin - user notes]
[user notes - settings]
1 个赞
ToddZ
2024 年8 月 16 日 10:06
29
我正在尝试这个，想知道：对于 staff_alias 用户，预期的通知和电子邮件行为是什么？
staff_alias 用户会收到一个随机字符串作为电子邮件地址，因此通常会发送的电子邮件会被跳过。
我无法为 staff alias 提供真实的电子邮件地址，因为 Discourse 会尝试向该随机字符串发送确认电子邮件。
staff_alias 是单行道吗？也许我遗漏了什么。是否有办法让它像 admin 一样充当真实帐户的“前端”，从而像往常一样接收通信？
1 个赞
nat
2024 年8 月 16 日 18:09
30
ToddZ:
staff_alias 是单向的吗？
是的。
在管理大型社区时，身份可能会非常棘手。当您允许许多“员工”以“员工别名”的身份发帖时，实际使用员工别名发帖的版主帐户也会显示给员工，如下图所示
Discourse:
如果您在员工别名背后放置一个“真实帐户”，那么将暴露许多其他用户选项，这使得很难审核是哪个员工对帐户进行了哪些更改。
您期望收到什么样的“沟通”？我觉得有另一种方法可以实现您希望达到的目标。
2 个赞
ToddZ
2024 年8 月 16 日 21:44
31
感谢您的回复，@nat 。我只是认为，如果我使用 staff_alias 发帖，用户可能会回复，而我不想忽略他们。
我曾担心没有人会看到此类通知——但此后我发现，我确实会收到发送到使用该别名的“父级”员工账户的电子邮件和通知。所以，这很棒。
还有几个遗留问题：
感谢您的任何建议。
经过更多实验，我感觉对事情的理解更近了一步……但插件主题可以提及通知的路由方式，并提供有关其他相关账户设置的指导。
3 个赞
nat
2024 年8 月 21 日 06:27
32
啊，这应该在插件本身中得到处理。这是我们在构建它时考虑不周的地方，所以我们应该修复它。
ToddZ:
禁用向 staff_alias 发送个人消息
这作为默认设置是有意义的。让我与我的产品团队核实一下。
1 个赞
ToddZ
2024 年8 月 21 日 17:39
37
你好 @nat – 插件似乎确实需要一些微调：
a.) 我尝试关闭 staff_alias 的电子邮件，它变成了一个黑洞。发送到“父”帐户的电子邮件和通知不会被触发。所以我会重新启用电子邮件，暂时忽略跳过的电子邮件通知。
b.) 禁用发送到 staff_alias 的私人消息并不能阻止管理员和版主等特权帐户向其发送消息——这些消息只有在查找时才能看到。也许也可以将这些消息路由到相关的“父”帐户？
这些对我来说还不是大问题，但我可以想象对于拥有更多员工和更繁忙活动的网站来说会存在问题。我会关注任何消息……谢谢！
2 个赞
ToddZ
2024 年8 月 31 日 17:21
38
我也遇到了同样的问题。看起来那个 PR 还在等待审查……
我会更新说明。 
