/admin/users/sync_sso エンドポイントを使用して SSO データを同期する場合、不要であってもアカウントからユーザー名を削除することはできません。つまり、ある名前を「なし」に変更することはできません。これは full_name_required = false（かつ sso_overrides_name = true）の設定で発生しています。
問題はおそらくここにあると思います：
ただし、Ruby/Discourse の知識が十分でないため、PR を提出するのは恐れています。
これは私には機能リクエストのように思えます。現時点では、このような場合に管理者 API を使用して名前をクリアできます。詳細は以下をご覧ください：
申し訳ありませんが、私は同意しません。これが機能リクエストではなくバグであるとはどうして言えるのか、理解できません。
他の API エンドポイントを使用できることは理解しています。しかし、/admin/users/sync_sso の主な目的は、まさにこのようなデータを同期させることです。すでにアカウント名フィールドの設定は可能です——それは機能しています。ただし、名前は常に必須フィールドであると想定しており、空白に設定することができません。そのため、データの同期を保つために使用することはできません。
以下のコードは、私のサンドボックス環境では期待通りに動作するようですが、現時点でプルリクエストを提出するには自信がありません。自由に使用したり、適応させたりしてください。
- if SiteSetting.sso_overrides_name && user.name != name && name.present?
- user.name = name || User.suggest_name(username.blank? ? email : username)
+ if SiteSetting.sso_overrides_name && user.name != name
+ if SiteSetting.full_name_required && name.present?
+ user.name = name || User.suggest_name(username.blank? ? email : username)
+ else
+ user.name = name
+ end
機能リクエストです。セマンティクスが曖昧です。名前の欠如は、
のいずれかを意味する可能性があります。
ここでプロトコルの変更を求めておられます。私は通常、混乱を招く API にならないよう、明示性を好みます。
なるほど、ご指摘の点はわかりました。
繰り返しになりますが、内部実装（や Ruby）については十分に理解していないのですが、そのリクエストで name フィールドが提供されたかどうかを確認する方法はないのでしょうか？もし全く提供されていなければ、アカウントの name フィールドには手を加えない。提供されていれば、それを設定する（空欄ならクリアする）。これでは、提供されたフィールドのみを同期するというプロトコルや挙動に従わないでしょうか？
もし私の理解が間違っていたり、意味が通じなかったりすれば申し訳ありません。ただ、私の理解の範囲で考えをまとめようとしています。
問題は、「name」パラメータが存在して空白に設定されている場合と、「name」パラメータが存在しない場合とで、プロトコルのセマンティクスが同じ（どちらも name を変更しない）という点です。
ここでの変更はプロトコルのセマンティクスの変更となります。name= とすれば name が空白になり、name の欠如は「name を変更しない」を意味するように変更することも可能ですが、既存のユーザーは現在の動作に依存しているため、技術的には破壊的変更となります。
なぜ名前を削除しようとしているのか、理由を説明してもらえますか？
私たちはすべてのユーザーの名前を削除するわけではありません。ユーザーは当社のウェブサイト（SSOプロバイダー）でアカウントを更新する際に、自分自身のデータを更新します。Discourseアカウント内のデータ（ユーザー名、名前、アバターなど）を同期させるためには、/admin/users/sync_sso に依存しています。名前は任意のフィールドであり、空白または空に設定可能です。
先ほど気づいたのですが、この問題は名前だけでなく、自己紹介文（bio）やアバターなどの更新にも発生します。これらが必須フィールドかどうかに関わらず、SSOレコードを空白または空に更新する必要がある場合、/admin/users/sync_sso を通じてそれらのレコードを同期させることはできません。
既存の動作に依存しているユーザーがいるというご指摘は理解できます（ただし、これまでこの問題の報告はなかったようですが）。しかし、これがプロトコルである場合、SSOレコードの同期という目的に対して重大な制限があるように思われます。
私もこの問題に直面しています。Discourse から、ユーザー自身が自分の個人情報（名前、アバター、自己紹介、カスタムフィールドなど）を削除できないため、想像できるような影響が生じています。現在の動作のセマンティクスを変更しないことに賛成ですが、SSO ペイロードなどでこれらの属性を false に設定できるようにし、明示的に削除を指示することはできませんか？
以前は、/admin/users/sync_sso への呼び出しと /u/{username} エンドポイントへの別の呼び出しを組み合わせて、名前をクリアしていました（名前の新しい値が空の場合）。
しかし、これも最近のバージョンで動作しなくなったようです。おそらく、名前を更新する前に sso_overrides_name = true をチェックするためでしょう。
そのため、現状では、SSO と sso_overrides_name = true を使用している場合、SSO プロバイダーが API を介して Discourse の名前フィールドをクリアすることは不可能になったようです。
この回避策について、@sam さん、何かお分かりになりますか？
sync_sso ルートに &clear_name のような追加のパラメータが必要だと思いますか？よくわかりません。これは非常にまれなケースのように感じます。名前が空白の場合のユースケースは何ですか？ユーザー名がない場合は、ユーザー名に設定し、UI で重複を抑制できるようにすればよいのではないでしょうか。
これがエッジケースだと考えるのが私には混乱します。おそらく、名前が必須フィールドである状況に慣れているのでしょう。
私たちは逆で、ユーザー名が誰もが持たなければならないもので、名前はオプションのフィールドです（prioritize_username_in_ux = true と full name required = false を使用しています）。Twitterアカウントのように、誰もがユーザー名/ハンドルを持たなければならず、オプションで名前も持つことができます。名前フィールド（または他の個人データ）をクリアしたいというのは、エッジケースのシナリオではないと思います。
現在、名前を入力すると、それを削除することは不可能です。これはsync_ssoの制限であり、ユーザーを更新するための追加のAPI呼び出しで回避していましたが、それも現在では機能しません。
検討しましたが、ユーザー名が本名であると誤解する人もいます。私たちは国際フォーラムを運営しており、何が個人の名前で何がユーザー名なのか（インターフェイス上の位置を除いて）はしばしば不明瞭です。
記憶が正しければ、アバターを削除する場合もsync_ssoで全く同じ問題が発生すると思います。これも機能しないと思われます。デフォルトアバター用のURLを独自に提供することで回避しています。
クリアまたはリセットできないフィールドが複数ある場合、クリア/リセットするフィールドの配列（またはCSVリスト）が必要になるかもしれません。
これを達成する方法について合意するには、何が必要でしょうか？ パラメータの追加、特別な値、2番目のAPI呼び出しなど、こちら側で実装することは何でも喜んで行います。しかし、私の見解では、現在の状況はエッジケースではありません。上記の@mentalstringと同様に、私は外部の真実の情報源と同期しており、プロフィール写真や表示名の設定はオプションです。ユーザーはそれらを持たないことが許可されています。Discourseでは設定しないことが可能です。SSOを使用しない場合、それらを自由に設定および削除できます。DiscourseConnectはこれを壊します。一度設定されると、それらを削除することは決してできません。これは私の意見では（非常に小さな）バグです。
プロトコルを変更することについての懸念は理解しています。そこでは空が現在のところ変更なしを意味します。個人的には同意しません。プロトコルを解釈するための簡単で合理的な方法であり、リスクはごくわずかだと考えています。名前とアバターのURL値を常に送信するが、時にはそれらを空白に設定し、古い値を保持することを意味すると期待するシステムを実装することは非常に奇妙でしょう。そして、そのようなシステムがもしあれば、その結果は名前とアバターが解除されるだけで、簡単な修正になるはずです。
しかし、いずれにせよ、その点については議論したくありません。しかし、これが不可欠な機能であるという主張をしたいのです。PRを行う用意はありますが、どのような解決策が受け入れられるかを知りたいだけです。
前もって感謝します。
少なくともnameとavatar_url、そしておそらく他のもの（websiteも？）でこれが起こることを考えると、いくつかの個別のclear_xの代わりに、クリアするフィールドのリストを持つreset_fieldsパラメータはどうでしょうか？
私たちにとっては、/u/{username}エンドポイントへの追加の呼び出しで修正できればすでに役立ちますが、それもいつの間にか機能しなくなりました。