Sim, esse é um ponto problemático. Deveria, na verdade, ter como padrão os e-mails do desenvolvedor, conforme definidos em app.yml, porque o desenvolvedor/administrador do sistema está muito mais interessado em implementar a atualização do que em dar suporte ao site (que pode ser uma equipe não técnica).
3 curtidas
Talvez a resposta aqui seja alterar a configuração de administrador new version emails de um alternador para uma lista separada por vírgulas de endereços de e-mail, com o padrão sendo o primeiro administrador do site que configura o site em primeiro lugar.
Dito isso, temos a regra de três? Eu não ouvi essa solicitação de mais ninguém. O contato oficial deve alcançar alguém sobre questões importantes relacionadas ao fórum e pode encaminhar o e-mail para a pessoa responsável por fazer as atualizações.
3 curtidas
Há uma grande chance de as pessoas não estarem cientes da existência desse recurso.
2 curtidas
Vamos ver… por padrão, o Discourse verifica atualizações de versão. Também por padrão, se uma nova versão estiver disponível, um e-mail é enviado para o endereço contact_email.
No assistente de configuração, eles são solicitados a preencher o campo contact_email.
Eu acho que é verdade que as pessoas podem não chegar tão longe na configuração inicial e podem nunca mais voltar para completar essa configuração de administrador. Poderíamos fazer mais para garantir que o Discourse incentive as pessoas a completá-la, para garantir que elas sejam alcançáveis para notificações críticas e em sua página “sobre” para assuntos urgentes.
Também é verdade que, para auto-hospedados, um endereço de e-mail para a pessoa que configura o site é fornecido durante a configuração em app.yml, e, portanto, uma experiência mais tranquila pode, de fato, ser enviar o e-mail para o endereço de e-mail em app.yml, como sugerido acima.
Ou outra ideia seria alterar a configuração do administrador para especificar um grupo para notificar, administrador padrão? Isso seria barulhento ou as pessoas pisariam umas nas outras em sites com muitos administradores, mas poderíamos adicionar uma nota ao guia de introdução do administrador para alterar o grupo nesse caso.
2 curtidas
Concordo que seria útil se os e-mails relacionados a atualizações fossem para um e-mail de desenvolvedor em vez de contact_email.
(contexto)
A principal razão é que o contact_email é listado publicamente como o e-mail de suporte para que qualquer pessoa possa entrar em contato para consultas gerais ou suporte.
Acredito que faria mais sentido vincular um e-mail como esse a um sistema de tickets de suporte operado por pessoal não técnico. Enquanto as notificações críticas sobre a segurança da instância do Discourse (como atualizações de segurança disponíveis) devem ir diretamente para um e-mail de administrador do servidor (idealmente sem a necessidade de uma conta de usuário criada para esse e-mail).
Um webhook também seria muito bom, o que tornaria possível enviar esses alertas críticos para Slack, Discord, etc.
3 curtidas
Eu acho que queremos fazer algo aqui.
Esta pode ser a solução mais fácil e rápida de implementar. Uma lista separada por vírgulas de endereços de e-mail é suportada, e eles não precisam necessariamente ter contas no site.
Podemos explicar como será usado na ferramenta de configuração e no guia do administrador.
Também é uma ótima ideia! Talvez possa ser adicionado como um plugin. Você poderia iniciar um tópico separado para sugerir isso?
Ótima ideia! Isso também parece uma solicitação de recurso separada - você pode iniciar outro tópico para sugerir isso e explicar sua ideia com mais detalhes?
2 curtidas