最初のメールアドレスでバウンスが続く場合、システムにセカンダリメールアドレスを試してもらいたいのですが。
可能でしょうか?もし不可能なら、Discourseにおけるセカンダリメールアドレスの目的は何ですか?
最初のメールアドレスでバウンスが続く場合、システムにセカンダリメールアドレスを試してもらいたいのですが。
可能でしょうか?もし不可能なら、Discourseにおけるセカンダリメールアドレスの目的は何ですか?
ユーザーがセカンダリメールアドレスからDiscourseの投稿にメールで返信すると、不明なユーザーとして拒否されるのではなく、メッセージが投稿されてしまいます。
フォーラムがトピックにメールを使用しない場合、セカンダリメールは完全に無駄になり、OPが尋ねたように使用できず、セカンダリログイン目的にも使用できないということですか?
もしそうなら、それはユーザーにとってほとんどノイズにすぎません(はい、知っています—セカンダリはMicrosoft、GoogleなどのSSOオプションが使用されている場合に存在します)。
この件に関する最初の議論はここにあります: https://meta.discourse.org/t/two-emails-for-one-user/16328。ここでは、議論が続いています: https://meta.discourse.org/t/additional-email-address-per-user-account-support/59847。
これは主に、ユーザーが複数のメールアドレスから投稿する場合に、メール経由で Discourse に投稿するための処理のために実装されたのだと思います。
プライマリメールアドレスへのメールがバウンスした場合に、Discourse がセカンダリメールアドレスにメールを送信しようとするような処理は何もありません。それが一部のケースで役立つ可能性があることは理解できます。
技術的には、Discourse が User.find_by_email を使用してユーザーを検索しようとする際に、セカンダリメールアドレスを使用してユーザーを見つけることができます。
ユーザーはセカンダリメールアドレスを使用して Discourse にログインできます。
Discourse へのログインに外部認証プロバイダーが使用される場合、認証プロバイダーから提供されるメールアドレスに基づいて、セカンダリメールアドレスからユーザーを見つけることができます。
興味深いことに、auth overrides email サイト設定が有効になっており、サイトの外部認証プロバイダーがユーザーのセカンダリメールアドレスを提供する場合、セカンダリメールアドレスがプライマリメールアドレスになり、元のプライマリメールアドレスは破棄されます。このケースは以前はログインエラーを引き起こしていたため、この動作は意図的なようです。どこで発生するかを特定するのに非常に時間がかかりました: discourse/app/models/user.rb at main · discourse/discourse · GitHub
これは、メインのメールアドレスが失敗した場合に、管理者またはモデレーターがセカンダリメールアドレスを使用してアカウント所有者に手動で連絡を試みることができるため重要ですか?
それ以外の場合、通常、有効なメールアドレスがないアカウントは終了されます。ただし、一部のメールは、誰かが支払いの延滞があるために一時的に配信不能として返送されます。
間違いなく、柔軟性が少し向上します。Discourseアカウントの作成に使用したメールアドレスへのアクセスを失ったユーザーのケースは、対処するのが難しい問題です。
はい、アカウントを持っていると主張するものの、メインのメールにアクセスできなかったり、パスワードを覚えていなかったりする人を認証するのは難しい場合があります。ここでのアカウントにセカンドメールを追加しましたが、これは別のサーバーを使用しているため、メインのメールに問題があった場合でも、もう一方が機能することを願っています。