Discourse Staff Alias

Discourse · June 29, 2020, 1:37am


	Summary	Discourse Staff Alias allows set groups to create topics and posts, as well as make edits, as an alias user.
	Repository Link	https://github.com/discourse/discourse-staff-alias
	Install Guide	How to install plugins in Discourse

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.

Enabling Staff Alias

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.

Using the Alias

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:

Keeping track of who used the 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:

Settings

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

Hosted by us? This plugin is available on our Enterprise tier.

Last edited by @Bas 2024-08-12T14:12:55Z

Check document
Perform check on document:

JammyDodger · June 10, 2023, 7:02pm

2 posts were split to a new topic: Can the Staff Alias also be used for replies?

sok777 · September 12, 2023, 11:19am

It seems we can’t add an existing user account. Why is that?
Screenshot 2023-09-12 at 12.17.48

JammyDodger · September 12, 2023, 11:29am

There’s a chance I made a mistake when writing up the instructions.

I also can’t get an existing user to be a staff alias now I test it again, which makes sense when I think about it. I’m not sure what led me to believe it was possible. I’ll update the instructions.

sok777 · September 12, 2023, 11:40am

Thanks! It’s a shame because I think it makes it unified when all staff members can use the site name or like a ‘master’ account that already exists. For example @Discourse

barto_95 · January 12, 2024, 10:49am

when i test to create subject, i received the error message

JammyDodger · January 12, 2024, 10:58am

Does your staff alias user have the right permissions to create a topic in that category? (do they have staff permissions)

barto_95 · January 12, 2024, 11:17am

Yes this is the problem …

thank you

barto_95 · January 22, 2024, 1:17pm

Its not possible to response on message replay on user with option staff alias i receive the error same above but if i use staff aliase to respond on message subject is ok

jordan-violet · May 15, 2024, 6:27am

What are the chances this could be extended to be a dynamic “post as another user” tool?

We have a use case where we have a product communications manager who needs to create new topics as other product managers in our organization. This tool seems like most of the functionality is there, but would require the ability to set the user being posted as dynamically.

fokx · May 24, 2024, 9:06am

I meet the same error every time I reply to some post that is not OP:

An error occurred: You are not permitted to view the requested resource.

After digging into this a little bit, I find the culprit lies at:

github.com

discourse/discourse-staff-alias/blob/5e1855a2321c32a8fd4c78988954fa57f29b9cb9/lib/discourse_staff_alias/posts_controller_extension.rb#L17


      
          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

The problem is:

params[:whisper] is "false", which is a String, so simply change this line to:

if !DiscourseStaffAlias.user_allowed?(existing_user) || params[:whisper] == "true"

…will solve the issue.

I made a simple PR: FIX: InvalidAccess when replying to non-original post by fokx · Pull Request #67 · discourse/discourse-staff-alias · GitHub

Heliosurge · August 1, 2024, 4:10pm

Hi Jordan,

I can think of a couple of options.

If your product manager is a full site mod they can use the wrench on the post to “change ownership” no plugins required

Bas · August 12, 2024, 2:15pm

Wanted to note that I just spent a fair amount of minutes trying to figure out why a mystery moderator was created on a site.

This user had a random hash as email, it looked fairly suspect.

I think it would be good to leave a staff-note, log the “grant moderation” in the staff log, or give some other indication that this user was created by a plugin

Heliosurge · August 14, 2024, 3:13am

If your self Hosted or the plan supports it. The plugin User Notes is very handy

ToddZ · August 16, 2024, 10:06am

I’m trying this out, and wondering: what is the expected behavior with regard to notifications and emails for the staff_alias user?

The staff_alias user gets a random string in place of an email address—so emails that would normally be sent are skipped.

I can’t give the staff alias a real email address, as Discourse tries to send a confirmation email to the random string.

Is staff_alias is a one-way street? Maybe I’m missing something. Is there—or should there be—a way to have it act as a “front” for a real account, like admin, that receives communications as usual?

nat · August 16, 2024, 6:09pm

Yes.

In managing larger communities, identity can be quite tricky. When you allow many ”staff” to post as the “staff alias”, the actual moderator account who used the staff alias to post is also shown to staff as seen in the screenshot

If you put a “real account” behind the staff alias, there are then many other user options that are exposed which makes it difficult to vet which staff did what changes to the account.

What kind of “communication” are you expecting to receive? I feel like there’s another way to get to what you hope to achieve.

ToddZ · August 16, 2024, 9:44pm

Thanks for responding, @nat. I simply figured that if I post with staff_alias, users may respond, and I wouldn’t want to overlook them.

I feared nobody would see such notifications – but I’ve since found that I do get these emails and notifications at the staff account that used the alias. So, that’s cool.

Couple of remaining questions:

The email Skipped log includes failures trying to send to the staff_alias bogus string. I’m guessing I can turn off all email settings for staff_alias, and emails will still be triggered and sent to the “parent” staff account…?
I can only see personal messages to staff_alias by digging into its profile via admin. Maybe it’s sensible to just disable personal messaging to staff_alias?

Thanks for any advice there.

I feel closer to understanding things after more experimenting… but the plugin topic could benefit from a mention of how notifications are routed, and some guidance around other relevant account settings.

nat · August 21, 2024, 6:27am

Ah, that should have been accounted for within the plugin itself. It is a lack of consideration when we built it so we should get that fixed.

This makes sense as a default. Let me check with my product team.

ToddZ · August 21, 2024, 5:39pm

Hi @nat – it does seem the plugin could use some fine tuning:

a.) I’ve tried turning off email for staff_alias, and it becomes a bit of a black hole. Emails & notifications to the “parent” account are not triggered. So I’ll re-enable email & ignore the skipped email notices for now.

b.) Disabling personal messaging to staff_alias doesn’t keep privileged accounts like admins and mods from messaging it – and those Messages are only seen if dug for. Maybe those could also be routed to the relevant “parent” account?

These things aren’t a huge concern for me yet, but I can imagine issues for sites with more staff and heavier activity. I’ll watch for any news… thanks!

ToddZ · August 31, 2024, 5:21pm

I just ran into this issue myself. Looks like that PR is still awaiting a review…

Topic		Replies	Views
Discourse Automation Plugin official , automation , included-in-core	46	18433	October 15, 2024
Discourse Chat Integration Plugin official , chat-integration	16	96432	October 9, 2024
Advice on a support forum Support	13	185	August 23, 2024
Force specific users through moderation Plugin	41	7188	December 20, 2022
Comment on a question instead of answering it Support	13	3465	December 14, 2023

Discourse Staff Alias

Enabling Staff Alias

Using the Alias

Keeping track of who used the Alias

Settings

Related Topics