Oui, c’est un point sensible. Cela devrait plutôt utiliser par défaut les developer_emails tels que définis dans app.yml car le développeur/administrateur système est beaucoup plus intéressé par la publication de la mise à jour que par le support du site web (qui pourrait être une équipe non technique).
3 « J'aime »
Peut-être que la réponse ici est de changer le paramètre d’administration new version emails d’un interrupteur à une liste d’adresses e-mail séparées par des virgules, par défaut au premier administrateur du site qui configure le site en premier lieu.
Cela dit, avons-nous la règle de trois ? Je n’ai entendu cette demande de personne d’autre. Le contact officiel est censé joindre quelqu’un au sujet des problèmes importants liés au forum, et peut transférer l’e-mail à la personne responsable des mises à jour.
3 « J'aime »
Il y a de fortes chances que les gens ignorent l’existence de cette fonctionnalité.
2 « J'aime »
Voyons voir… par défaut, Discourse vérifie les mises à jour de version. Également par défaut, si une nouvelle version est disponible, un e-mail est envoyé à l’adresse contact_email.
Dans l’assistant de configuration, ils sont invités à remplir le champ contact_email.
Je suppose qu’il est vrai que les gens pourraient ne pas aller aussi loin lors de la configuration initiale et ne jamais revenir pour compléter ce paramètre d’administration. Nous pourrions faire plus pour nous assurer que Discourse incite les gens à le compléter, afin de nous assurer qu’ils sont joignables pour les notifications critiques et sur leur page “À propos” pour les questions urgentes.
Il est également vrai que pour les auto-hébergeurs, une adresse e-mail de la personne qui configure le site est fournie lors de la configuration dans app.yml, et donc une expérience plus fluide pourrait en effet être d’envoyer l’e-mail à l’adresse e-mail dans app.yml, comme suggéré ci-dessus.
Ou une autre idée serait de modifier le paramètre d’administration pour spécifier un groupe à notifier, par défaut les administrateurs ? Cela pourrait être bruyant ou les gens se marcher sur les pieds sur les sites avec de nombreux administrateurs, mais nous pourrions ajouter une note au guide de démarrage pour les administrateurs pour changer le groupe dans ce cas.
2 « J'aime »
Je suis d’accord qu’il serait utile que les e-mails liés aux mises à jour soient envoyés à une adresse e-mail de développeur plutôt qu’à l’adresse contact_email.
(contexte)
La raison principale est que l’adresse contact_email est publiquement indiquée comme l’adresse e-mail de support pour toute personne souhaitant contacter pour des demandes générales ou du support.
Je pense qu’il serait plus logique de lier une adresse e-mail comme celle-ci à un système de tickets de support géré par du personnel non technique. Tandis que les notifications critiques concernant la sécurité de l’instance Discourse (comme les mises à jour de sécurité disponibles) devraient être envoyées directement à une adresse e-mail d’administrateur serveur (idéalement sans avoir besoin d’un compte utilisateur créé pour cette adresse e-mail).
Un webhook serait également très apprécié, ce qui permettrait d’envoyer ces alertes critiques à Slack, Discord, etc.
3 « J'aime »
Je pense que nous voulons faire quelque chose ici.
C’est peut-être le fruit le plus facile à cueillir et le plus simple à mettre en œuvre. Une liste d’adresses e-mail séparées par des virgules est prise en charge, et elles n’ont pas nécessairement besoin d’avoir des comptes sur le site.
Nous pouvons expliquer comment il sera utilisé dans l’outil de configuration et dans le guide d’administration.
C’est aussi une bonne idée ! Peut-être pourrait-elle être ajoutée en tant que plugin. Pourriez-vous lancer un sujet séparé pour la suggérer ?
Bonne idée ! Cela ressemble également à une demande de fonctionnalité distincte - pouvez-vous lancer un autre sujet pour la suggérer et expliquer votre idée plus en détail ?
2 « J'aime »