当サイトでは以下のような設定になっています：
大規模なメールマガジンリストを保有しており、このリストに登録されているすべてのメールアドレスを「事前に承認」したいと考えています。サイト訪問者が、事前に承認リストに含まれるメールアドレスと紐付いた Facebook または Google アカウントでサインアップまたはログインを試みた場合、スタッフによる承認を待つことなく、すぐにサイトを利用できるようになります。
理想としては、メールアドレスごとにグループ所属も事前に設定できるようにしたいと考えています。
これは可能でしょうか？Discourse API を利用するソリューションであれば歓迎します。
残念ながら、これは全く機能しません！
主な理由は、ローカルログインが有効になっていないと招待が機能しないためです。そのため、おそらくすべてを処理する非常にカスタムなプラグインか、要件を満たす外部認証システムが必要になるでしょう。
スティーブさん、ようこそ！
インポートスクリプトでアドレスを取り込めば、正しい処理が行われるはずです。通知やサマリーが大量に送られてしまうリスクを避けたいのであれば、それらのユーザーを「アクティブ」に設定しないようにしてください。
これはコンソールから比較的簡単に実行できるはずです。ホスティング環境であれば、API 経由でも可能だと思います。
「Large」とはどういう意味ですか？
"Large"とは、約5,000件を指します。UIのどこかで手動入力したくないほどの規模です。
@pfaffman さん、APIを通じてユーザーを作成する方法についてもう少し詳しく教えていただけますか？ユーザー作成には ‘password’ フィールドが必須のようですが、ローカルログインが無効になっている場合、これは不可能だと推測されます：POST /users
使用ケースについて少し補足します。同様の検討をしている他の人のために：私たちはユーザーにソーシャルアカウントでのログインを促したいと考えています。Discourseへの参加を促している人々の多くは技術に詳しくないため、別のユーザー名とパスワードを管理する必要がないことを知ってほしいのです。
しかし、Discourseの現在のメール招待機能では、ユーザーがパスワードを選択する必要があり、これはユーザーにとっての簡素化という私たちの目標を損なっています。
もしかしたら、別の方法で目標を達成できるかもしれませんか？必要であればローカルログインを有効にするのも構いませんが、招待されたユーザーが、パスワードを一切必要とせず、ソーシャルアカウントでログインできることを明確に認識できるようにしたいと考えています。
皆様、ありがとうございます！Discourseをより多くの人に使っていただけるようになることを大変楽しみにしています。
パスワードの作成を免除しつつ、ソーシャルログインで使用するメールアドレスを必ず知らせることを義務付けるだけでは、同じことにはなりません。ソーシャルログインを利用すれば、パスワードを設定せずに済むからです。私はよく（最近は少なくなりましたが）Gmailアカウントでのログインを拒否し、妻もほぼ常にそうしています。また、メールでのログインは非常に便利で、パスワードが不要になります。しかし、話がそれてしまいました。
API がパスワードを要求する場合は、ランダムなパスワードを生成すればよいでしょう。知らないし必要でもないパスワードを持っていることは、実質的にパスワードがないのと同じです。
以前、GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group · GitHub というツールを作成しました。動作を保証するわけではありませんが、かなり近い状態まで持っていけるはずです。非アクティブ化されたユーザーを作成したいので、それを修正する必要がありますが、何を削除すべきかはかなり明確でしょう。（問題を解決したいだけで、予算がある場合は、お気軽にご連絡ください。）
よく見ないと気づかなかったのですが、メール招待を受け入れたユーザーにはパスワードフィールドが必須ではないことを認めます。ユーザーが別のメールアドレスを選択してパスワードを作成できるべきだというご指摘はもっともです。特にサイト内でソーシャルログインが有効になっている場合、パスワードが必須ではないことが UI でより明確に示されていれば、ずっと安心できると思います。現在の UI では、パスワードを作成したくないと強く思わない限り、これが必須ではないことに気づくのは難しいように思います。そろそろ袖をまくり上げて、UX を改善する PR を作成しようかなと思います 
サンプルコードを確認しました。ありがとうございます！参考までに、適切な API 呼び出しを行うためには、以下のハックが必要でした：Using the API to create a user on an SSO only system - #13 by DylannCordel - それでも、私が想定していたユースケースには合致していないと思います。なぜなら、これではユーザーへのアクティベーション用メールが送信されてしまうからです。私は、ユーザーが将来的にサイトにログインする際に、シームレスに「そのまま動作する」体験を提供したいと考えていたため、このメール送信は避けたいと思っていました。
また、こちらのソリューションも少し試してみました：How to manually add user in discourse? - #10 - この方法で存在させたいユーザーアカウントをハック的に追加すれば機能するとは思いますが、最終的には、コンテナ内の環境を直接変更してこれらの変更を加えるリスクを負う価値があるかどうかは確信が持てません。
というわけで、全体的に、私が期待していたワークフローは、実際にはサポートされていない、あるいは想定されていないワークフローのようです。UI がいつか（もしかしたら）改善されるまで、それで納得するしかありません。
皆様、ありがとうございました！
いくつかの異なる点が混同されているようです。
ソーシャルログインは、認証が Facebook、Twitter、Google などで処理されるため、パスワードをスキップします。
招待リンクはパスワードを一時的にオプションにしますが、再度招待リンクから「ログイン」する必要があります。ただし、この機能は非常に制限が強化されたため、実質的にはもう機能しなくなっています。その後ログインするには、メール経由でパスワードのリセットを申請する必要があり、その際にパスワードを設定することになります。
長い話になりますが、招待機能は人々に最小限の手間でできるだけ早く参加し、返信してもらうために設計されていますが、パスワード設定を永遠にスキップさせることを意図したものではありません。
以下の手順は現時点で機能しているようです：
確かに、これは本来機能すべきではないのかもしれません。私が以前「UI が不明確だ」と述べた点は、実際には機能ではなく、この回避策を利用する人を減らすために意図的に設計されたバグなのかもしれません。それでも、メールで招待されたがパスワード作成を望まず、ソーシャルログインの他の利点（プロフィール画像の引き継ぎなど）を優先するユーザーにとっては、許容できる選択肢だと思われます。
ソーシャルログインではなくパスワードを希望するユーザーもいるという以前の指摘は確かに理解できますし、そのような人々のためにその機能を無効化すべきではないと確信しています。それでもなお、パスワードを希望しないユーザーを招待したり、簡単に設定したりするための明確で簡単な方法を実現したいと考えています。
そのパスで問題ありませんが、前述の理由により、パスワードなしのケースは一時的なものだとご理解ください。
したがって、いずれにせよユーザーは「何か」を行う必要があり、パスワードが一切不要な状態が恒久的な現状となることはありません。
なるほど。最終的にはユーザーがパスワードを作成するか、SNS アカウントを連携させる必要がありますね。ありがとうございます！
メールログイン（またはソーシャルログイン）で問題なければ、パスワードは必要ありません。