Ich habe mit dem discourse/discourse_dev Docker-Image (auf einem Windows 11 Laptop) experimentiert und dabei einen kleinen Reibungspunkt im Entwickler-Workflow festgestellt.
Wenn Discourse im Entwicklungsmodus ohne konfigurierte ausgehende E-Mail ausgeführt wird:
1. Die Anmelde-/Login-Seite ist über Ember CLI (localhost:4200) erreichbar.
2. Sie können ein Benutzerkonto erstellen.
3. Aber das Login wird blockiert, da eine E-Mail-Bestätigung erforderlich ist.
Die Umgehungslösung scheint die manuelle Aktivierung des Kontos in der Rails-Konsole zu sein, zum Beispiel:
Gibt es einen empfohlenen Entwickler-Workflow, um das erste Administratorkonto zu erstellen, wenn E-Mail nicht konfiguriert ist?
Zum Beispiel:
• Sollten Entwickler SMTP auch in der Entwicklungsumgebung konfigurieren?
• Gibt es dafür eine Hilfsaufgabe (rake admin:create usw.)?
• Wäre es sinnvoll, wenn der Entwicklungscontainer den Login des ersten Benutzers ohne E-Mail-Bestätigung erlauben würde?
Ich frage hauptsächlich, um einen reibungsloseren Einrichtungsprozess für neue Entwickler zu dokumentieren, die mit dem Entwicklungscotainer experimentieren.
Danke! Das hat das Problem gelöst – ich war bei meinen Experimenten mit dem discourse_dev-Container nicht auf bin/rails admin:create gestoßen.
Was mich anfangs verwirrt hat, war, dass der normale UI-Anmeldeprozess bis zur Kontoerstellung funktioniert, die Anmeldung dann aber durch die E-Mail-Bestätigung blockiert wird, wenn SMTP nicht konfiguriert ist.
Für jemanden, der nur die Entwicklungsumgebung erkundet, sieht es so aus, als ob der Anmeldevorgang fehlschlägt, es sei denn, man weiß von dem Hilfsprogramm.
Es wäre vielleicht hilfreich, bin/rails admin:create explizit in der Dokumentation zur Entwicklungseinrichtung für den Docker-Entwicklungscontainer zu erwähnen, da neue Mitwirkende oft keine SMTP-Konfiguration haben.
Wenn Sie in Ihrer Entwicklungsumgebung E-Mail-Zugriff benötigen, können Sie auch MailHog ausführen.
Dazu müssen Sie lediglich eine neue Befehlszeile in Ihrem Discourse-Verzeichnis öffnen und mailhog ausführen. Wenn Sie dann localhost:8025 besuchen, können Sie E-Mails sehen, die normalerweise gesendet würden, ohne dass etwas konfiguriert werden muss.
Ich denke, der Unterschied besteht darin, dass der dokumentierte Pfad d/boot_dev --init den Admin-Benutzer bereits erstellt. Meine Verwirrung entstand also durch das Experimentieren in der Dev-Umgebung, anstatt diesen genauen Init-Ablauf von Anfang bis Ende zu durchlaufen.
Der Tipp mit MailHog ist ebenfalls hilfreich. Mir war nicht bewusst, dass das Dev-Setup Bestätigungs-E-Mails lokal über mailhog und localhost:8025 abfangen kann. Das erklärt den vorgesehenen Workflow, falls jemand den normalen Registrierungs-/E-Mail-Bestätigungsweg nutzt.
Das schlüssigere mentale Modell scheint also folgendes zu sein:
Für das Standard-Docker-Dev-Setup: d/boot_dev --init verwenden und beim Auffordern das Admin-Konto erstellen.
Zum Testen von E-Mail-/Registrierungsflows: mailhog starten und Nachrichten unter localhost:8025 anzeigen.
Falls separat benötigt: bin/rails admin:create ist der manuelle Helfer zum Erstellen eines Admin-Kontos.
Das klärt die Verwirrung auf – danke.
Eine kleine, separate Frage, während ich die Dev-Oberfläche erkunde: Wofür werden die kleinen Symbol-Schaltflächen in der vertikalen Symbolleiste verwendet? Ich sehe sie in der Oberfläche, bin mir aber nicht sofort sicher, ob es sich um normale Benutzerschnittstellen-Steuerelemente, Admin-Verknüpfungen oder Entwicklungs-/Debug-Hilfen handelt.
Das ist die Entwickler-Symbolleiste. Du kannst den abgesicherten Modus, die ausführliche Lokalisierung und bevorstehende Änderungen umschalten. Du kannst auch Plugin-Ausgänge und Blöcke anzeigen.