Discourse Staff Alias

[Discourse]

	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

As this is an official plugin maintained by the Discourse team, support, bug, ux, and feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Click on a link below to get one started.

 Support  Bug  UX  Feature

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:

[sok777 (sok)]

@Discourse

You can use either an existing user account, or enter a new name for one to be created:

It seems we can’t add an existing user account. Why is that?

[JammyDodger]

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 (sok)]

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]

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

[JammyDodger]

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

[barto_95]

Yes this is the problem …

thank you

[barto_95]

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]

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]

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:

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

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 (Dan DeMontmorency)]

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 (Bas van Leeuwen)]

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 (Dan DeMontmorency)]

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

Discourse User Notes

Summary Discourse User Notes provides the ability to share notes with other staff about a user. Normal users cannot see these notes and are designed for staff to be able to privately note down important information other staff may need to know. Repository Link https://github.com/discourse/discourse-user-notes Install Guide How to install plugins in Discourse Configuration The User Notes plugin can be enabled either by the toggle or …

[ToddZ]

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 (Natalie T)]

@ToddZ

Is staff_alias is a one-way street

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

@Discourse

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]

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 (Natalie T)]

@ToddZ

The email Skipped log includes failures trying to send to the staff_alias bogus string.

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.

@ToddZ

disable personal messaging to staff_alias

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

[ToddZ]

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

@ToddZ

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…?

(…)

Maybe it’s sensible to just disable personal messaging to staff_alias ?

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]

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