Ja, das ist ein Schwachpunkt. Es sollte stattdessen standardmäßig auf die developer_emails gesetzt werden, wie in app.yml definiert, da der Entwickler/Systemadministrator viel mehr daran interessiert ist, das Update zu pushen, als an der Website-Unterstützung (die auch ein nicht-technisches Team sein könnte).
3 „Gefällt mir“
Vielleicht besteht die Antwort hier darin, die Admin-Einstellung new version emails von einem Umschalter in eine durch Kommas getrennte Liste von E-Mail-Adressen zu ändern, die standardmäßig auf den ersten Website-Administrator gesetzt wird, der die Website überhaupt einrichtet.
Davon abgesehen, gibt es die Regel der drei? Ich habe diese Anfrage von niemand anderem gehört. Der offizielle Kontakt soll jemanden über wichtige Probleme im Zusammenhang mit dem Forum erreichen und die E-Mail an die Person weiterleiten, die für die Durchführung von Updates zuständig ist.
3 „Gefällt mir“
Es besteht eine hohe Wahrscheinlichkeit, dass die Leute sich der Existenz dieser Funktion nicht bewusst sind.
2 „Gefällt mir“
Mal sehen… standardmäßig prüft Discourse auf Versionsupdates. Ebenfalls standardmäßig wird eine E-Mail an die Adresse contact_email gesendet, wenn eine neue Version verfügbar ist.
Im Einrichtungsassistenten werden sie aufgefordert, das Feld contact_email auszufüllen.
Ich schätze, es stimmt, dass die Leute bei der Ersteinrichtung vielleicht nicht so weit kommen und nie zurückkehren, um diese Admin-Einstellung abzuschließen. Wir könnten mehr tun, um sicherzustellen, dass Discourse die Leute anstößt, damit sie es abschließen, um sicherzustellen, dass sie für kritische Benachrichtigungen erreichbar sind und auf ihrer Über-uns-Seite für dringende Angelegenheiten.
Es stimmt auch, dass für Self-Hosters während der Einrichtung in app.yml eine E-Mail-Adresse für die Person, die die Website einrichtet, angegeben wird. Eine reibungslosere Erfahrung wäre es daher vielleicht tatsächlich, die E-Mail an die E-Mail-Adresse in app.yml zu senden, wie oben vorgeschlagen.
Oder eine andere Idee wäre, die Admin-Einstellung zu ändern, um eine Gruppe anzugeben, die benachrichtigt werden soll, standardmäßig ein Admin? Das wäre laut oder Leute, die sich gegenseitig auf Seiten mit vielen Admins auf die Füße treten, aber wir könnten eine Notiz in der Admin-Anleitung für den Einstieg hinzufügen, um die Gruppe in diesem Fall zu ändern.
2 „Gefällt mir“
Ich stimme zu, dass es hilfreich wäre, wenn Update-bezogene E-Mails an eine Entwickler-E-Mail und nicht an die contact_email gesendet würden.
(Kontext)
Der Hauptgrund dafür ist, dass die contact_email öffentlich als Support-E-Mail für allgemeine Anfragen oder Support aufgeführt ist.
Ich glaube, es wäre sinnvoller, eine solche E-Mail mit einem Support-Ticketing-System zu verknüpfen, das von nicht-technischem Personal betrieben wird. Während die kritischen Benachrichtigungen bezüglich der Sicherheit der Discourse-Instanz (wie verfügbare Sicherheitsupdates) direkt an eine Server-Admin-E-Mail gesendet werden sollten (idealerweise ohne dass ein Benutzerkonto für diese E-Mail erstellt werden muss).
Ein Webhook wäre ebenfalls sehr schön, der es ermöglichen würde, diese kritischen Benachrichtigungen an Slack, Discord usw. zu senden.
3 „Gefällt mir“
Ich denke, wir wollen hier etwas tun.
Dies ist vielleicht die am einfachsten zu erreichende und zu implementierende Funktion. Eine durch Kommas getrennte Liste von E-Mail-Adressen wird unterstützt, und diese müssen nicht unbedingt Konten auf der Website haben.
Wir können erklären, wie sie im Einrichtungs-Tool und im Admin-Handbuch verwendet wird.
Auch eine schöne Idee! Könnte vielleicht als Plugin hinzugefügt werden. Könnten Sie einen separaten Thread starten, um es vorzuschlagen?
Schöne Idee! Dies fühlt sich auch wie eine separate Funktionsanfrage an – können Sie einen weiteren Thread starten, um sie vorzuschlagen und Ihre Idee detaillierter zu erklären?
2 „Gefällt mir“