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:
C’è la possibilità che abbia commesso un errore nello scrivere le istruzioni.
Inoltre, non riesco più a far sì che un utente esistente sia un alias dello staff ora che lo testo di nuovo, il che ha senso quando ci penso. Non sono sicuro di cosa mi abbia portato a credere che fosse possibile. Aggiornerò le istruzioni.
Grazie! È un peccato perché penso che renda unificato quando tutti i membri dello staff possono usare il nome del sito o un account ‘master’ che esiste già. Ad esempio @Discourse
Non è possibile rispondere a un messaggio con un alias di staff quando si risponde a un replay di un utente. Ricevo lo stesso errore di cui sopra, ma se uso un alias di staff per rispondere a un messaggio con oggetto, funziona.
Quali sono le probabilità che questo possa essere esteso per diventare uno strumento dinamico “posta come un altro utente”?
Abbiamo un caso d’uso in cui un product communications manager deve creare nuovi argomenti come altri product manager della nostra organizzazione. Questo strumento sembra avere la maggior parte delle funzionalità, ma richiederebbe la possibilità di impostare dinamicamente l’utente per cui si sta postando.
Volevo segnalare che ho passato parecchio tempo a cercare di capire perché fosse stato creato un moderatore misterioso su un sito.
Questo utente aveva un hash casuale come email, sembrava piuttosto sospetto.
Penso che sarebbe opportuno lasciare una nota per lo staff, registrare la “concessione della moderazione” nel log dello staff, o dare qualche altra indicazione che questo utente è stato creato da un plugin
Sto provando questo e mi chiedo: qual è il comportamento previsto per quanto riguarda le notifiche e le email per l’utente staff_alias?
L’utente staff_alias riceve una stringa casuale al posto di un indirizzo email, quindi le email che verrebbero normalmente inviate vengono saltate.
Non posso fornire all’alias dello staff un indirizzo email reale, poiché Discourse tenta di inviare un’email di conferma alla stringa casuale.
L’alias dello staff è una strada a senso unico? Forse mi sfugge qualcosa. Esiste, o dovrebbe esistere, un modo per farlo agire come un “front” per un account reale, come admin, che riceve le comunicazioni come al solito?
Nella gestione di community più grandi, l’identità può essere piuttosto complicata. Quando si consente a molti “staff” di pubblicare come “staff alias”, l’account del moderatore effettivo che ha utilizzato lo staff alias per pubblicare viene anche mostrato allo staff, come si vede nello screenshot
Se si mette un “account reale” dietro lo staff alias, ci sono molte altre opzioni utente che vengono esposte, il che rende difficile verificare quale staff ha apportato quali modifiche all’account.
Che tipo di “comunicazione” ti aspetti di ricevere? Sento che c’è un altro modo per ottenere ciò che speri di realizzare.
Grazie per la risposta, @nat. Mi era semplicemente venuto in mente che se avessi pubblicato con staff_alias, gli utenti avrebbero risposto e non avrei voluto trascurarli.
Temevo che nessuno avrebbe visto tali notifiche, ma da allora ho scoperto che ricevo queste email e notifiche sull’account staff che utilizzava l’alias. Quindi, questo è fantastico.
Un paio di domande rimanenti:
Il registro delle email saltate include errori nel tentativo di inviare alla stringa fittizia staff_alias. Suppongo di poter disattivare tutte le impostazioni email per staff_alias, e le email verranno comunque attivate e inviate all’account staff “genitore”…?
Posso vedere messaggi personali a staff_alias solo scavando nel suo profilo tramite amministrazione. Forse è sensato disabilitare semplicemente la messaggistica personale a staff_alias?
Grazie per qualsiasi consiglio.
Mi sento più vicino a capire le cose dopo ulteriori esperimenti… ma l’argomento del plugin potrebbe beneficiare di una menzione su come vengono instradate le notifiche e di alcune indicazioni su altre impostazioni dell’account pertinenti.
Ah, questo avrebbe dovuto essere considerato all’interno del plugin stesso. È una mancanza di considerazione quando lo abbiamo costruito, quindi dovremmo risolvere il problema.
Questo ha senso come impostazione predefinita. Verifico con il mio team di prodotto.
Ciao @nat – sembra che il plugin potrebbe aver bisogno di qualche aggiustamento:
a.) Ho provato a disattivare le email per staff_alias, e diventa un po’ un buco nero. Le email e le notifiche all’account “genitore” non vengono attivate. Quindi riattiverò le email e ignorerò per ora gli avvisi di email saltate.
b.) Disabilitare la messaggistica personale a staff_alias non impedisce ad account privilegiati come amministratori e moderatori di inviarle – e quei messaggi vengono visti solo se cercati. Forse anche quelli potrebbero essere indirizzati all’account “genitore” pertinente?
Queste cose non sono una grande preoccupazione per me ancora, ma posso immaginare problemi per siti con più staff e attività più intensa. Terrò d’occhio eventuali novità… grazie!
Aggiornerò le istruzioni. 
