Discourse 스태프 별칭

[Discourse]

	요약	Discourse Staff Alias 플러그인은 설정된 그룹이 별칭 사용자로 토픽과 게시물을 생성하고, 편집을 수행할 수 있도록 합니다.
	리포지토리 링크	https://github.com/discourse/discourse-staff-alias
	설치 가이드	Discourse에서 플러그인 설치하는 방법

이 플러그인은 Discourse 팀이 유지 관리하는 official(공식) 플러그인입니다. Support(지원), Contribute > Bug(버그), Contribute > UX(UX), Contribute > Feature(기능) 요청은 Meta의 해당 카테고리에서 적절한 플러그인 태그와 함께 게시할 수 있습니다. 아래 링크를 클릭하여 요청을 시작해 보세요.

 지원  버그  UX  기능

Discourse Staff Alias 플러그인은 특정 그룹이 별칭 사용자로 토픽과 게시물을 생성하고 편집을 수행할 수 있게 합니다. 이는 스태프가 개인 사용자명을 노출하지 않고도 문의에 응답하거나 공지사항을 게시해야 하는 상황에서 유용할 수 있습니다.

Staff Alias 활성화

설치 후, admin/plugins 페이지에서 접근할 수 있는 설정에서 Staff Alias 플러그인을 활성화할 수 있습니다:

이 플러그인은 기본적으로 비활성화되어 있으며, 활성화하기 전에 staff alias username 관리자 설정에 별칭을 위한 새로운 사용자명을 추가해야 합니다:

플러그인이 활성화되면 해당 사용자명을 가진 사용자가 생성됩니다.

---

별칭 사용

활성화된 후, 편집기(Composer)의 액션 드롭다운 메뉴를 통해 Staff Alias를 켤 수 있으며, 허용된 그룹에 속한 사용자는 Staff Alias를 사용하여 토픽과 게시물을 생성하고 편집을 수행할 수 있습니다:

그 후 토픽/게시물/편집은 Staff Alias가 생성한 것처럼 표시됩니다:

---

별칭 사용 기록 추적

허용된 그룹 중 하나에 속해 있다면, 토픽이나 게시물을 생성하거나 편집을 수행한 사람이 누구인지에 대한 메모도 볼 수 있습니다:

---

설정

이름	설명
staff alias enabled	discourse-staff-alias 플러그인 활성화
staff alias username	별칭 사용자의 사용자명
staff alias allowed groups	Staff Alias 사용자로 게시할 수 있는 그룹

우리 회사에서 호스팅을 이용하고 계신가요? 이 플러그인은 Enterprise 티어에서 사용할 수 있습니다.

[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:

lib/discourse_staff_alias/posts_controller_extension.rb

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

자체 호스팅을 사용 중이거나 해당 플랜이 이를 지원하는 경우, #customization:플러그인 사용자 노트(User Notes)가 매우 유용합니다.

Discourse User Notes

Summary Share private notes with other staff about a user that normal users cannot see. Install Guide This plugin is bundled with Discourse core. There is no need to install the plugin separately. Configuration The User Notes plugin can be enabled either by the toggle or from its settings, both accessible from your /admin/plugins page: [/admin/plugin - user notes] [user notes - settings] Features Sometimes staff members want to share notes about…

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