Il plugin Discourse Staff Alias consente a determinati gruppi di creare argomenti e post, nonché di apportare modifiche, come utente alias. Questo può essere utile in situazioni in cui i membri dello staff devono rispondere a richieste o fare annunci senza rivelare i propri nomi utente personali.
Abilitazione di Staff Alias
Una volta installato, il plugin Staff Alias può essere abilitato dalle sue impostazioni, accessibili dalla pagina admin/plugins:
Questo plugin è disabilitato per impostazione predefinita e, prima di abilitarlo, è necessario aggiungere un nuovo nome utente per l’alias nell’impostazione amministrativa staff alias username:
Una volta abilitato il plugin, verrà creato un utente con quel nome utente.
Utilizzo dell’Alias
Una volta abilitato, l’alias dello staff può essere attivato o disattivato tramite il menu a discesa delle azioni del compositore. Gli utenti appartenenti ai gruppi autorizzati potranno quindi scegliere di creare argomenti e post, nonché di apportare modifiche, utilizzando l’alias dello staff:
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!
Ospitato da noi? Questo plugin è disponibile nel nostro piano Enterprise.
Aggiornerò le istruzioni. 
