Sí, eso es un punto débil. Debería ser por defecto a los correos electrónicos de los desarrolladores definidos en app.yml porque el desarrollador/administrador del sistema está mucho más interesado en implementar la actualización que en el soporte del sitio web (que podría ser un equipo no técnico en su totalidad).
3 Me gusta
Quizás la respuesta aquí sea cambiar la configuración de administrador new version emails de un interruptor a una lista separada por comas de direcciones de correo electrónico, que por defecto sea el primer administrador del sitio que configura el sitio en primer lugar.
Dicho esto, ¿tenemos la regla de tres? No he escuchado esta solicitud de nadie más. El contacto oficial debe comunicarse con alguien sobre problemas importantes relacionados con el foro y puede reenviar el correo electrónico a la persona encargada de realizar las actualizaciones.
3 Me gusta
Es muy probable que la gente no sea consciente de la existencia de esta función.
2 Me gusta
Veamos… por defecto, Discourse comprueba las actualizaciones de versión. También por defecto, si hay una nueva versión disponible, se envía un correo electrónico a la dirección contact_email.
En el asistente de configuración, se les pide que rellenen el campo contact_email.
Supongo que es cierto que la gente podría no llegar tan lejos en la configuración inicial y podría no volver nunca para completar esa configuración de administrador. Podríamos hacer más para asegurarnos de que Discourse impulse a la gente para que la complete, para asegurarnos de que sean contactables para notificaciones críticas y en su página “acerca de” para asuntos urgentes.
También es cierto que para los autoalojados, se proporciona una dirección de correo electrónico de la persona que configura el sitio durante la configuración en app.yml, por lo que una experiencia más fluida podría ser, de hecho, enviar el correo electrónico a la dirección de correo electrónico en app.yml, como se sugirió anteriormente.
O bien, otra idea sería cambiar la configuración de administrador para especificar un grupo al que notificar, ¿administrador por defecto? Eso sería ruidoso o la gente se pisaría los talones en sitios con muchos administradores, pero podríamos añadir una nota a la guía de inicio para administradores para cambiar el grupo en ese caso.
2 Me gusta
Estoy de acuerdo en que sería útil si los correos electrónicos relacionados con las actualizaciones fueran a un correo electrónico de desarrollador en lugar de a contact_email.
(contexto)
La razón principal es que contact_email se enumera públicamente como el correo electrónico de soporte para que cualquiera pueda contactar para consultas generales o soporte.
Creo que tendría más sentido vincular un correo electrónico como ese a un sistema de tickets de soporte operado por personal no técnico. Mientras que las notificaciones críticas sobre la seguridad de la instancia de Discourse (como las actualizaciones de seguridad disponibles) deberían ir directamente a un correo electrónico de administrador del servidor (idealmente sin necesidad de crear una cuenta de usuario para ese correo electrónico).
Una webhook también sería muy agradable, lo que permitiría enviar estas alertas críticas a Slack, Discord, etc.
3 Me gusta
Creo que queremos hacer algo aquí.
Esta podría ser la fruta más fácil de alcanzar y la más sencilla de implementar. Se admite una lista de direcciones de correo electrónico separadas por comas, y no necesariamente tienen que tener cuentas en el sitio.
Podemos explicar cómo se utilizará en la herramienta de configuración y en la guía del administrador.
¡También es una buena idea! Quizás podría añadirse como un plugin. ¿Podrías iniciar un tema separado para sugerirlo?
¡Buena idea! Esto también parece una solicitud de función separada. ¿Puedes iniciar otro tema para sugerirla y explicar tu idea con más detalle?
2 Me gusta