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 티어에서 사용할 수 있습니다.
41개의 좋아요
sok777
(sok)
17
기존 사용자 계정을 추가할 수 없는 것 같습니다. 그 이유는 무엇인가요?
설명을 작성할 때 실수를 했을 수도 있습니다. 
다시 테스트를 해보니 기존 사용자를 스태프 별명으로 설정할 수 없더군요. 생각해보니 그럴 만도 합니다. 왜 가능하다고 생각했는지 모르겠네요. 
설명을 업데이트하겠습니다. 
4개의 좋아요
sok777
(sok)
19
감사합니다! 모든 직원이 사이트 이름이나 이미 존재하는 ‘마스터’ 계정을 사용할 수 있으면 통합된 느낌을 줄 것 같아 아쉬워요. 예를 들어 @Discourse처럼요.
4개의 좋아요
barto_95
(🇵🇹 | )
20
주제를 생성하는 테스트를 수행했을 때, 
에러 메시지가 나타났습니다.
직원 별칭 사용자가 해당 카테고리에서 주제를 생성할 수 있는 권한이 있습니까? (직원 권한이 있습니까?)
1개의 좋아요
스태프 별칭 옵션을 사용하여 사용자의 메시지 답장에 응답할 수 없습니다. 위에서 언급한 것과 동일한 오류가 발생하지만, 스태프 별칭을 사용하여 메시지에 응답하면 제목은 정상적으로 동작합니다.
이 기능을 동적인 “다른 사용자로 게시” 도구로 확장할 가능성은 얼마나 될까요?
우리는 제품 커뮤니케이션 매니저가 조직 내 다른 제품 매니저로 새 토픽을 생성해야 하는 사용 사례가 있습니다. 이 도구는 대부분의 기능이 갖춰져 있는 것으로 보이지만, 게시할 사용자를 동적으로 설정할 수 있는 기능이 필요합니다.
4개의 좋아요
fokx
25
OP가 아닌 게시글에 답글을 달 때마다 동일한 오류가 발생합니다:
오류가 발생했습니다: 요청한 리소스를 볼 권한이 없습니다.
조금 더 파고들어 보니 원인은 다음 위치에 있었습니다:
https://github.com/discourse/discourse-staff-alias/blob/5e1855a2321c32a8fd4c78988954fa57f29b9cb9/lib/discourse_staff_alias/posts_controller_extension.rb#L17
문제는 다음과 같습니다:
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
조던, 안녕?
몇 가지 옵션을 생각해 볼 수 있겠네.
제품 매니저가 전체 사이트 관리자(full site mod)라면, 플러그인 없이 게시물에서 렌치 아이콘을 클릭하여 "소유권 변경"을 수행할 수 있어.
1개의 좋아요
Bas
(Bas van Leeuwen)
27
최근 어떤 사이트에서 정체불명의 모더레이터가 생성된 이유를 파악하려고 꽤 오랜 시간을 보냈다는 점을 공유하고 싶습니다.
해당 사용자의 이메일 주소는 무작위 해시 값으로 되어 있었고, 상당히 의심스러운 상황이었습니다.
이 사용자가 플러그인에 의해 생성되었음을 알 수 있도록 스태프 노트를 남기거나, '모더레이션 권한 부여’를 스태프 로그에 기록하거나, 기타 다른 방식으로 표시하는 것이 좋다고 생각합니다
2개의 좋아요
Heliosurge
(Dan DeMontmorency)
28
자체 호스팅을 사용 중이거나 해당 플랜이 이를 지원하는 경우, #customization:플러그인 사용자 노트(User Notes)가 매우 유용합니다.
1개의 좋아요
ToddZ
29
현재 이 기능을 시험해 보고 있는데, staff_alias 사용자의 알림과 이메일에 대한 예상 동작이 어떻게 되는지 궁금합니다.
staff_alias 사용자는 이메일 주소 대신 랜덤 문자열을 가지므로, 정상적으로 발송되어야 할 이메일은 건너뛰어집니다.
Discourse가 랜덤 문자열로 확인 이메일을 보내려고 시도하기 때문에, staff_alias에 실제 이메일 주소를 설정할 수 없습니다.
staff_alias는 일방통행(one-way)인가요? 제가 무언가를 놓치고 있는 건지 모르겠습니다. 관리자(admin)와 같은 실제 계정으로 하여금 통상대로 통신을 수신하도록, 이를 '프론트(front)'로 활용하는 방법이 있거나, 있어야 하는 건 아닌가요?
1개의 좋아요
nat
(Natalie T)
30
네.
큰 커뮤니티를 관리할 때 신원 파악은 꽤 까다로울 수 있습니다. 많은 "스태프"가 "스태프 별칭"으로 게시물을 작성하도록 허용하면, 스태프 별칭을 사용해 게시물을 작성한 실제 모더레이터 계정도 스태프에게 스크린샷에 보이는 것처럼 표시됩니다.
스태프 별칭 뒤에 "실제 계정"을 두게 되면, 계정에 대한 변경 사항을 누가 수행했는지 확인하기가 어려워지는 등 여러 다른 사용자 옵션이 노출됩니다.
어떤 종류의 "소통"을 기대하고 계신가요? 원하시는 결과를 달성하기 위한 다른 방법이 있을 것 같습니다.
2개의 좋아요
ToddZ
31
@nat 님, 답변해 주셔서 감사합니다. staff_alias로 게시물을 올리면 사용자들이 답변을 할 수 있을 것 같았고, 그렇게 되면 그 답변들을 놓칠 수 있을 것 같아 이렇게 문의드렸습니다.
이런 알림을 아무도 보지 못할까 봐 걱정했는데, 나중에 staff_alias를 사용한 스태프 계정으로 이러한 이메일과 알림이 실제로 전송되는 것을 확인했습니다. 다행이네요.
남은 질문이 두 가지 있습니다:
-
Skipped log 이메일에는 staff_alias라는 잘못된 문자열로 전송을 시도하다 실패한 기록이 포함되어 있습니다. staff_alias의 모든 이메일 설정을 꺼도 이메일은 여전히 트리거되어 “부모” 스태프 계정으로 전송되는 것일까요?
-
staff_alias로 온 개인 메시지는 관리자 권한으로 해당 프로필을 직접 살펴봐야만 확인할 수 있습니다. staff_alias에 대한 개인 메시지 기능을 비활성화하는 것이 더 합리적인 방법일까요?
이 부분에 대해 조언을 주시면 감사하겠습니다. 
더 많은 실험을 통해 이해에 가까워지고 있는 것 같습니다… 하지만 플러그인 주제에 알림이 어떻게 라우팅되는지에 대한 언급과, 기타 관련 계정 설정에 대한 안내가 포함되면 좋겠습니다.
3개의 좋아요
nat
(Natalie T)
32
아, 그건 플러그인 자체에서 처리되었어야 하는 부분입니다. 처음 만들 때 이 부분을 고려하지 못한 실수이니 수정하겠습니다.
기본값으로 이 설정을 적용하는 것이 타당합니다. 제품 팀과 확인해 보겠습니다.
2개의 좋아요
ToddZ
37
안녕하세요 @nat – 플러그인이 좀 더 세밀한 조정이 필요해 보입니다:
a.) staff_alias의 이메일을 끄려고 해봤는데, 이게 일종의 블랙홀이 됩니다. ‘부모’ 계정에 대한 이메일 및 알림이 트리거되지 않습니다. 그래서 지금은 이메일을 다시 활성화하고 건너뛴 이메일 알림은 무시하겠습니다.
b.) staff_alias에 대한 개인 메시징을 비활성화해도 관리자나 모더레이터와 같은 특권 계정이 메시지를 보내는 것을 막을 수 없습니다 – 그리고 그런 메시지는 직접 찾아봐야만 볼 수 있습니다. 이런 메시지도 해당 ‘부모’ 계정으로 라우팅할 수 있을까요?
이 문제들은 아직 저에게는 큰 우려 사항은 아니지만, 스태프가 더 많고 활동이 더 활발한 사이트에서는 문제가 될 수 있다고 생각합니다. 관련 뉴스를 지켜보겠습니다… 감사합니다!
2개의 좋아요
ToddZ
38
나도 방금 이 문제를 겪었습니다. 해당 PR이 아직 리뷰를 기다리고 있는 것 같네요…
