何が足りないのでしょうか？WordPress SSO を介して初めてユーザーがログインしました。承認が必要になるように設定しているのですが、このオプションはここに表示されるべきではありませんか？このユーザーを承認する方法がわかりません 
管理メニューには、承認待ちのユーザーがいるという通知があります。
素晴らしい。修正いただき、ありがとうございます。これは仕様でしょうか？「アクティベーション」の概念がどのように関わるのか、よく理解できていません。毎回、アクティベートと承認の両方を行う必要があるのでしょうか？
SSO と「ユーザーの承認が必要」の両方を有効にすることは、少し特殊なケースだと思います。どのように動作することが想定されているのかはわかりません。理想的には、SSO を有効にした場合、ユーザーの承認は SSO プロバイダーサイト（WordPress）側で処理されるべきです。残念ながら、これを実現するにはいくつかのカスタムコードが必要です。その設定方法の詳細については、How to prevent some WP users from being able to login to Discourse をご覧ください。
「ユーザーの承認が必要」と SSO の両方が有効な場合のユーザー承認の動作について調べています。何か注目すべき点が見つかったら、ここで報告します。
@simon さん、素晴らしいご回答をいただきありがとうございます。以前に言及しなかったのは、単なる記憶に基づくものだったためです（私の場合、記憶はいつも疑わしいものです）。しかし…
さっき、新しいユーザーがサインインしたところ、すぐに承認オプションが利用可能になりました。つまり、まずアクティベーション段階を経る必要はありませんでした。
そのため、この状況は私にとって依然として非常に混乱しています。2 人の直近の新しい利用者間でプロセスが異なった理由を説明できるような設定変更は行っておりません。混乱が支配的です…
さらに何か分かりましたら、お知らせいたします。
改めてありがとうございます。
それは許可されていないと思っていたのですが。SSO ホストがユーザー管理を担当するはずです。私の理解では、SSO にアカウントを持つ特定のユーザーに Discourse へのアクセスを許可したくない場合は、グループで管理するか、何らかの方法で Discourse へのログインを拒否する必要があります。
ログイン後に一部のユーザーをアクティブ化し、かつ承認する必要があるという奇妙な状況はありますが、どうやら機能しているようです。現在の設定では、各ユーザーが初めてログインを試みた後、管理者がリクエストを承認する必要があります。それはまあ許容範囲です（後述）。つまり、SSOの使用とユーザーの承認という2つの設定は問題なさそうです。
とはいえ、ユーザーが最初のログインを試みる前に、特定のユーザーを事前に承認できないのは残念であり、大きな問題です。つまり、私たち（管理者）が事前に誰が誰であるかを完全に把握しているにもかかわらず、ユーザーはログインするまで待たなければなりません。
@simon 氏は、これは Discourse の観点からはエッジケースであると指摘していますが、WooCommerce サイトで通常の製品とメンバーシップの両方を販売するのは非常に一般的です。私もその状況にあり、これはかなり一般的なシナリオです。そのため、私のユーザーは「顧客」と「メンバー」という2つの（重なり合う）論理的なセットに分かれています。メンバーのリストを事前に承認し、彼らが承認を待つ必要がないようにしたいと考えています。後でこれを自動化する可能性もありますが、それは9月1日のフォーラムローンチ後になるため、残念です。
なるほど！Discourse 内でこれらのグループを手動で操作するのではなく、WooCommerce を設定して管理したいのですね。それに関するトピックがいくつかあります。多少のカスタムコードが必要ですが、いくつかの例も用意されています。参考までに、私は通常、そのような作業に対して1000ドルから1500ドルを請求しています。
@pfaffman さん、ありがとうございます。時間さえあれば、自分でも対応できる可能性が高いので、現在調査を進めています。ローンチ時には「承認が必要になる」という前提を設け、迅速に対応することにします。ローンチ後は、このプロセスを何らかの方法で自動化できないか検討します。
完全自動化されたソリューションに関する希望について、一点だけ補足させてください。
私は、非メンバーが実際にログインできるが、その後（メンバー関連のグループに所属していないなどの理由で）何らかの操作ができなくなるようなソリューションは避けたいと考えています。代わりに、非メンバーの場合、ログイン自体を失敗させたいと考えています。できれば、その理由を説明するページへリダイレクトする機能も備わっていることが望ましいです。
言い換えれば、「メンバーでない場合はログインをブロックする」方が、「ログインは許可するが、リソースへのアクセスをブロックする」よりも優先されます。
再度、ありがとうございます。
@simon 数分間、この課題に対する可能な解決策を調査してみました。その過程で、こちらのページであなたに出会いました 
WP Discourse – WordPress plugin | WordPress.org
私のビジネスは WordPress と WooCommerce を中心に展開しており、すべての統合では可能な限りタグを使用してユーザーを管理しています。WP Fusion がこれらを統合する接着剤の役割を果たしていますが、結論から言えば、すべてのユーザー（顧客、メンバーなど）にタグが割り当てられています。
この文脈を踏まえて、私が実現したいのは、WordPress 側で独自の関数を作成し、何らかのロジック（私の場合はユーザーに特定のタグが付いているかどうかを確認するだけのシンプルなもの）を実装し、その条件が満たされない場合はログインを拒否することです。
思いつく限り、そのロジックを実装できるフックは存在するでしょうか？もしあれば素晴らしい解決策となり、ログイン処理を依然として WordPress が完全に制御できる状態に保つことができます。
よろしくお願いいたします。
はい、ご要望の機能を実装する方法については、以下のトピックで説明されています：https://meta.discourse.org/t/how-to-prevent-some-wp-users-from-being-able-to-login-to-discourse/93234。トピック内の 2 つ目の投稿には、利用できる 2 つのサンプル関数が記載されています。コード例に含まれている /* Some condition that returns true if the user doesn't meet the membership requirement */ というコメントを、実際の条件判定コードに置き換える必要があります。
素晴らしい！以前そのトピックを閲覧したときは誤解していたようですが、まさに必要なものですね。実装とテスト（有名な最期の言葉ですが！）が終われば、これで完璧です！
ありがとうございます。
なるほど、そうだろうな……そして……
やっぱりね！
もう解決への道筋が見えてきていて何よりです。
確かに。@pfaffman さん、その点を見落としてしまい申し訳ありません。また、お手伝いいただきありがとうございます。ミラーリングされた Discourse VPS を設定し、ミラーリングされた Web サイトと連携させるために移動します。すべて順調であれば、まもなく稼働開始できる見込みです。