Environnement de développement : meilleure façon d'amorcer le premier compte administrateur sans e-mail ?

Dev
1

J’expérimente avec l’image Docker discourse/discourse_dev (sur un ordinateur portable Windows 11) et j’ai remarqué un petit point de friction dans le flux de travail des développeurs.

Lors de l’exécution de Discourse en mode développement sans configuration d’e-mail sortant :
\t1.\tVous pouvez accéder à la page d’inscription/connexion via Ember CLI (localhost:4200).
\t2.\tVous pouvez créer un compte utilisateur.
\t3.\tMais la connexion est bloquée car la confirmation par e-mail est requise.

La solution de contournement semble être d’activer manuellement le compte dans la console Rails, par exemple :

u = User.find_by(username: "admin")
u.approved = true
u.email_tokens.update_all(confirmed: true, expired: true)
u.save!

Cela fonctionne, mais je me demandais :

Existe-t-il un flux de travail de développement recommandé pour amorcer le premier compte administrateur lorsque l’e-mail n’est pas configuré ?

Par exemple :
\t•\tLes développeurs devraient-ils normalement configurer SMTP même en environnement de développement ?
\t•\tExiste-t-il une tâche d’aide pour cela (rake admin:create, etc.) ?
\t•\tSerait-il judicieux que le conteneur de développement autorise la connexion du premier utilisateur sans confirmation par e-mail ?

Je pose la question principalement pour documenter un processus d’installation plus fluide pour les nouveaux développeurs qui expérimentent avec le conteneur de développement.

2

Oui, il en existe une :

3

Merci ! Cela résout le problème - je n’étais pas tombé sur bin/rails admin:create en expérimentant avec le conteneur discourse_dev.

Ce qui m’a initialement confus, c’est que le flux d’inscription de l’interface utilisateur normale fonctionne jusqu’au point de création du compte, mais la connexion est ensuite bloquée par la confirmation par e-mail si l’SMTP n’est pas configuré.

Pour quelqu’un qui explore simplement l’environnement de développement, cela donne l’impression que le flux de connexion est cassé à moins de connaître la tâche d’aide.

Il pourrait être utile de mentionner explicitement bin/rails admin:create dans la documentation de configuration du développement pour le conteneur de développement Docker, car les nouveaux contributeurs n’ont souvent pas de configuration SMTP.

4

Je ne suis pas sûr que ce soit nécessaire dans ce guide car il est indiqué

Donc, la création de l’utilisateur administrateur semble déjà faire partie du flux de travail

5

Si vous avez besoin d’un accès par e-mail dans votre environnement de développement, vous pouvez également exécuter mailhog.

Tout ce que vous avez à faire est d’ouvrir une nouvelle ligne de commande dans votre répertoire Discourse et d’exécuter mailhog. Ensuite, si vous visitez localhost:8025, vous pourrez voir les e-mails qui seraient normalement envoyés, sans avoir besoin de configurer quoi que ce soit.

image
image1920×882 97.8 KB

6

Merci à tous les deux — cela a du sens.

Je pense que la distinction réside dans le fait que le chemin documenté d/boot_dev --init crée déjà l’utilisateur administrateur, donc ma confusion venait d’expérimentations dans l’environnement de développement plutôt que de suivre ce flux d’initialisation exact de bout en bout.

L’astuce concernant MailHog est également utile. Je n’avais pas réalisé que la configuration de développement pouvait capturer localement les e-mails de confirmation via mailhog et localhost:8025, ce qui explique le flux de travail prévu si quelqu’un utilise le chemin normal d’inscription/confirmation par e-mail.

Ainsi, le modèle mental plus fluide semble être le suivant :

  1. Pour la configuration Docker de développement standard, utilisez d/boot_dev --init et créez le compte administrateur lorsque vous y êtes invité.
  2. Si vous testez les flux d’e-mail ou d’inscription, exécutez mailhog et consultez les messages sur localhost:8025.
  3. Si nécessaire séparément, bin/rails admin:create est l’outil manuel pour créer un compte administrateur.

Cela lève la confusion — merci.

Une petite question distincte pendant que j’explore l’interface utilisateur de développement : à quoi servent les petits boutons icônes dans la barre d’outils verticale ? Je les vois dans l’interface, mais je ne suis pas immédiatement certain s’il s’agit de contrôles normaux destinés aux utilisateurs, de raccourcis administrateur ou d’aides au développement/débogage.

7

Celles-là ?
image

C’est la barre d’outils de développement. Vous pouvez activer ou désactiver le mode sans échec, la localisation détaillée et les modifications à venir. Vous pouvez également afficher les emplacements et les blocs des plugins.