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:
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:
Há uma chance de eu ter cometido um erro ao escrever as instruções.
Também não consigo fazer com que um usuário existente seja um alias de staff agora que testo novamente, o que faz sentido quando penso nisso. Não tenho certeza do que me levou a acreditar que era possível. Vou atualizar as instruções.
Obrigado! É uma pena porque acho que fica unificado quando todos os membros da equipe podem usar o nome do site ou uma conta ‘mestra’ que já existe. Por exemplo, @Discourse
Não é possível responder à mensagem com um alias de staff em resposta a uma mensagem de um usuário. Recebo o mesmo erro acima, mas se eu usar um alias de staff para responder a uma mensagem com assunto, funciona.
Quais são as chances de isso ser estendido para ser uma ferramenta dinâmica de “postar como outro usuário”?
Temos um caso de uso em que um gerente de comunicação de produto precisa criar novos tópicos como outros gerentes de produto em nossa organização. Esta ferramenta parece ter a maior parte da funcionalidade, mas exigiria a capacidade de definir dinamicamente o usuário que está sendo postado.
Se o seu gerente de produto for um moderador completo do site, ele poderá usar a chave inglesa na postagem para “alterar a propriedade” sem a necessidade de plugins.
Gostaria de observar que passei um bom tempo tentando descobrir por que um moderador misterioso foi criado em um site.
Este usuário tinha um hash aleatório como e-mail, parecia bastante suspeito.
Acho que seria bom deixar uma nota da equipe, registrar a “concessão de moderação” no log da equipe ou dar alguma outra indicação de que este usuário foi criado por um plugin
Estou testando isso e me pergunto: qual é o comportamento esperado em relação a notificações e e-mails para o usuário staff_alias?
O usuário staff_alias recebe uma string aleatória em vez de um endereço de e-mail — portanto, os e-mails que normalmente seriam enviados são ignorados.
Não posso dar ao alias de staff um endereço de e-mail real, pois o Discourse tenta enviar um e-mail de confirmação para a string aleatória.
O staff_alias é uma rua de mão única? Talvez eu esteja perdendo alguma coisa. Existe — ou deveria existir — uma maneira de ele atuar como um “front” para uma conta real, como admin, que recebe comunicações normalmente?
Ao gerenciar comunidades maiores, a identidade pode ser complicada. Quando você permite que muitos “funcionários” postem como o “alias de funcionário”, a conta real do moderador que usou o alias de funcionário para postar também é mostrada aos funcionários, como visto na captura de tela
Se você colocar uma “conta real” por trás do alias de funcionário, haverá muitas outras opções de usuário expostas, o que torna difícil verificar quais funcionários fizeram quais alterações na conta.
Que tipo de “comunicação” você espera receber? Sinto que há outra maneira de chegar ao que você espera alcançar.
Obrigado por responder, @nat. Eu simplesmente imaginei que, se postasse com staff_alias, os usuários poderiam responder, e eu não gostaria de ignorá-los.
Eu temi que ninguém visse tais notificações – mas desde então descobri que recebo esses e-mails e notificações na conta de staff que usava o alias. Então, isso é bom.
Algumas perguntas restantes:
O log de e-mails pulados inclui falhas ao tentar enviar para a string fictícia staff_alias. Eu imagino que posso desativar todas as configurações de e-mail para staff_alias, e os e-mails ainda serão acionados e enviados para a conta de staff “pai”…?
Eu só consigo ver mensagens pessoais para staff_alias vasculhando seu perfil via admin. Talvez seja sensato apenas desativar mensagens pessoais para staff_alias?
Obrigado por qualquer conselho.
Sinto-me mais perto de entender as coisas após mais experimentação… mas o tópico do plugin poderia se beneficiar de uma menção de como as notificações são roteadas e alguma orientação sobre outras configurações de conta relevantes.
Olá @nat – parece que o plugin poderia usar um pouco de ajuste:
a.) Tentei desativar o e-mail para staff_alias, e ele se torna um pouco um buraco negro. E-mails e notificações para a conta “pai” não são acionados. Então, reativarei o e-mail e ignorarei os avisos de e-mail pulados por enquanto.
b.) Desativar mensagens pessoais para staff_alias não impede que contas privilegiadas como administradores e moderadores enviem mensagens para ela – e essas mensagens só são vistas se forem procuradas. Talvez essas também pudessem ser roteadas para a conta “pai” relevante?
Essas coisas não são uma grande preocupação para mim ainda, mas posso imaginar problemas para sites com mais staff e atividade mais intensa. Ficarei atento a qualquer novidade… obrigado!
Vou atualizar as instruções. 
