Sì, questo è un punto dolente. Dovrebbe piuttosto impostare come predefiniti gli indirizzi developer_emails definiti in app.yml perché il dev/sysadmin è molto più interessato a distribuire l’aggiornamento che al supporto del sito web (che potrebbe essere un team non tecnico a tutti gli effetti).
3 Mi Piace
Forse la risposta qui è cambiare l’impostazione dell’amministratore new version emails da un interruttore a un elenco separato da virgole di indirizzi email, impostato di default sul primo amministratore del sito che configura il sito in primo luogo.
Detto questo, abbiamo la regola dei tre? Non ho sentito questa richiesta da nessun altro. Il contatto ufficiale dovrebbe raggiungere qualcuno per questioni importanti relative al forum e può inoltrare l’email alla persona responsabile degli aggiornamenti.
3 Mi Piace
È molto probabile che le persone non siano a conoscenza dell’esistenza di questa funzionalità.
2 Mi Piace
Vediamo… per impostazione predefinita, Discourse verifica la presenza di aggiornamenti di versione. Inoltre, per impostazione predefinita, se è disponibile una nuova versione, viene inviata un’e-mail all’indirizzo contact_email.
Nella procedura guidata di configurazione, viene loro richiesto di compilare il campo contact_email.
Suppongo sia vero che le persone potrebbero non arrivare così lontano alla prima configurazione e potrebbero non tornare mai più per completare tale impostazione amministrativa. Potremmo fare di più per assicurarci che Discourse spinga le persone a completarla, in modo da essere raggiungibili per notifiche critiche e sulla loro pagina “informazioni” per questioni urgenti.
È anche vero che per gli self-hoster, un indirizzo e-mail della persona che configura il sito viene fornito durante la configurazione in app.yml, e quindi un’esperienza più fluida potrebbe effettivamente essere quella di inviare l’e-mail all’indirizzo e-mail in app.yml, come suggerito sopra.
Oppure un’altra idea sarebbe quella di modificare l’impostazione amministrativa per specificare un gruppo da notificare, l’amministratore predefinito? Sarebbe rumoroso o le persone si intralcerebbero a vicenda sui siti con molti amministratori, ma potremmo aggiungere una nota alla guida introduttiva per amministratori per modificare il gruppo in quel caso.
2 Mi Piace
Concordo sul fatto che sarebbe utile se le email relative agli aggiornamenti andassero a un’email di uno sviluppatore anziché a contact_email.
(context)
Il motivo principale è che la contact_email è elencata pubblicamente come email di supporto per chiunque desideri contattare per richieste generali o supporto.
Credo che avrebbe più senso collegare un’email del genere a un sistema di ticketing di supporto gestito da personale non tecnico. Mentre le notifiche critiche riguardanti la sicurezza dell’istanza Discourse (come gli aggiornamenti di sicurezza disponibili) dovrebbero andare direttamente all’email dell’amministratore del server (idealmente senza la necessità di creare un account utente per tale email).
Sarebbe anche molto utile un webhook, che renderebbe possibile inviare questi avvisi critici a Slack, Discord, ecc.
3 Mi Piace
Penso che vogliamo fare qualcosa qui.
Questo potrebbe essere il frutto più facile da cogliere e il più semplice da implementare. È supportato un elenco di indirizzi email separati da virgole e non devono necessariamente avere account sul sito.
Possiamo spiegare come verrà utilizzato nello strumento di configurazione e nella guida dell’amministratore.
Anche questa è una bella idea! Forse potrebbe essere aggiunto come plugin. Potresti avviare un argomento separato per suggerirlo?
Bella idea! Anche questa sembra una richiesta di funzionalità separata: puoi avviare un altro argomento per suggerirla e spiegare la tua idea in modo più dettagliato?
2 Mi Piace