こんにちは。以前のDrupal移行のバックアップから、2回のテストインストールを行いました。これは、FQDNが正しく設定され、メールが機能する別のVPSに、新しいDiscourseインスタンスとして復元したものです。インポーターインスタンスはVPSのIPアドレスのみを使用しており、メールは設定されていませんでした。これがこの問題に関係しているかどうかわかりませんが、バックアップ復元テストの両方で、復元が完了し、管理者アカウント作成ページに移動した後、メールが送信されないためアカウントを有効化できません。回避策として、./launcher enter app、rake admin:create を使用しました。その後、Webアプリケーションにログインでき、メールテストを正常に実行できます。すべてのユーザーのメールを有効にすると、他のユーザーアカウントはパスワードリセットメールを正常に受信できます。したがって、これは、復元後のデフォルト設定で、非スタッフユーザーにメールが送信されないというバグのようです。管理者ユーザーとして定義されたメールアドレスは、アカウントが検証される前でもスタッフと見なされるべきだと思います。
これは、インポートスクリプトが管理者アカウントを作成しなかったことを示唆しています。developer_email アドレスを使用してログインまたはアカウントを作成するだけで問題ありません。
これは、バックアップの復元によって非スタッフのメールが無効になり、そのユーザーがスタッフではないためである可能性が高いです。
そうかもしれませんね？新しいサイトと移行では、確かに鶏と卵の問題です。ユーザーを developer_emails に追加すればうまくいくと思います。
スクリプトに次のようなものを追加することもできます。
User.create(username: 'pat-the-admin', email: 'pat@user.com',password: 'very-safe-123', active: true, name: "Pat User") unless User.find_by_email('pat@user.com`)
Jay、返信ありがとうございます。ええ、そのようです。しかし、コンソールを使用して一時的な新しい管理者アカウントを有効にし、ユーザーリストを確認したところ、以前のDrupalのユーザー名が自動的にDiscourseの管理者ステータスを受け取ったことがわかりました。
app.ymlでは次のようになっています。
DISCOURSE_DEVELOPER_EMAILS: 'new-discourse-user@email.com,old-drupal-user@email.com'
はい。アカウントが有効になるまで、ユーザーはスタッフではないと私は疑っています。通常行うことは、インポートサイトでGoogle認証を使用し、ログインできるようにしたいユーザーがDEVELOPER_EMAILSに含まれており、Gmailアドレスを持っていることを確認することです。
「いいね！」 1