شكرًا لك! هذا يحل المشكلة - لم أكن قد صادفت الأمر bin/rails admin:create أثناء تجربتي مع حاوية discourse_dev.
ما أربكني في البداية هو أن مسار التسجيل بواجهة المستخدم العادية يعمل حتى نقطة إنشاء الحساب، ولكن يتم حظر تسجيل الدخول بعد ذلك بسبب تأكيد البريد الإلكتروني إذا لم يتم إعداد SMTP.
بالنسبة لشخص يستكشف بيئة التطوير للتو، فإن هذا يجعل مسار تسجيل الدخول يبدو معطلاً ما لم تكن تعرف المهمة المساعدة.
قد يكون من المفيد ذكر bin/rails admin:create بشكل صريح في وثائق إعداد التطوير لحاوية تطوير Docker، لأن المساهمين الجدد غالبًا لن يكون لديهم إعداد SMTP.
إذا كنت بحاجة إلى الوصول إلى البريد الإلكتروني في بيئة التطوير الخاصة بك، يمكنك أيضًا تشغيل mailhog.
كل ما عليك فعله هو فتح سطر أوامر جديد في دليل Discourse الخاص بك وتشغيل mailhog. بعد ذلك، إذا قمت بزيارة localhost:8025 يمكنك رؤية رسائل البريد الإلكتروني التي كانت سترسل عادةً، دون الحاجة إلى تكوين أي شيء.
أعتقد أن التمييز يكمن في أن مسار d/boot_dev --init الموثق ينشئ بالفعل مستخدم المسؤول، لذا فإن حيرتي نشأت من التجربة في بيئة التطوير بدلاً من اتباع تدفق التهيئة هذا بالضبط من البداية إلى النهاية.
نصيحة MailHog مفيدة أيضًا. لم أكن أدرك أن إعداد التطوير يمكنه التقاط رسائل التأكيد محليًا عبر mailhog وlocalhost:8025، وهو ما يوضح سير العمل المقصود إذا استخدم شخص ما مسار التسجيل/تأكيد البريد الإلكتروني العادي.
إذن يبدو أن النموذج الذهني الأكثر سلاسة هو:
لإعداد Docker القياسي للتطوير، استخدم d/boot_dev --init وأنشئ حساب المسؤول عند الطلب.
إذا كنت تختبر تدفقات البريد الإلكتروني/التسجيل، شغّل mailhog واعرض الرسائل على localhost:8025.
إذا لزم الأمر بشكل منفصل، فإن bin/rails admin:create هي الأداة اليدوية لإنشاء حساب المسؤول.
هذا يزيل اللبس — شكرًا لك.
سؤال صغير منفصل أثناء استكشاف واجهة المستخدم للتطوير: ما هي وظيفة أزرار الأيقونات الصغيرة في شريط الأدوات العمودي؟ يمكنني رؤيتها في الواجهة، لكنني لست متأكدًا فورًا مما إذا كانت أدوات تحكم عادية للمستخدمين، أو اختصارات للمسؤولين، أو أدوات مساعدة للتطوير/التصحيح.
