ユースケースの背景は Restrict exposure of full name to certain groups で説明しました。Discourse を地域の公立学校に関する議論を促進するために使用しており、ターゲットユーザーは主に保護者やその他の地域住民です。バランスを取りたいと考えています。
- 一方で、サイトを匿名ブラウジングに開放する（検索エンジンがインデックスできるように、メンバーでなくてもアクセスできるように、原則としてオープン/透明にするなど）
- 他方で、個人を特定できる情報をクローラーや通りすがりの非メンバーに不必要に公開することを避ける — コミュニティ内で名前を共有することを人々に許可したいと考えており、多くの人がそうすることにためらいがあることを解消したいと考えています。
当初、「投稿での表示名」を無効にし、「ユーザープロフィールを非公開にする」を有効にすれば、匿名ユーザーへの名前漏洩を防げると考えていました — しかし、そうではないことに気づきました。（そして、TOSとFAQで既に約束していました 
）
匿名ユーザーだけにフルネームへのアクセスを拒否すれば目的は達成できます。しかし、グループメンバーシップに基づいてアクセスを制御する方が簡単なので、それを利用することにしました — これにより、私たちのサイトでは >=TL1 へのアクセスを制限できるようになり、さらに良くなります。（現在、サインアップには招待が必要ですが、それを廃止したいと考えています。）
この問題/トピックを調査する中で、同様または類似の要望が他にも言及されているのを見かけました。例えば、「このグループだけが名前を見れるようにしたい」といったものです…これも解決できます。
あなたへの質問です（製品に関する質問と見なされるかもしれません！）:
enable_names 設定は、「ユーザーにフルネームを表示しない」という意味ですか、それとも「このサイトではフルネームを一切使用しない」という意味ですか？
この点について、コード自体やこのようなトピック/問題から、根本的な不明確さがあるように感じています — ある人は一方の意味で理解し、ある人はもう一方の意味で理解しています。
「いいね！」 4
RGJ
(Richard - Communiteq)
30
この件に進展はありますか？これは最も簡単に実装でき、かつ最も大きなプラスの影響をもたらすように思われます。
「いいね！」 4
同意します。管理者はトグルのオン・オフを切り替えることなく、フルネームにアクセスできるべきです。特に、実名を隠すことが重要な理由があります（少なくとも私たちのフォーラムでは）。
「いいね！」 3
ked
(Kenny DuBose)
32
このトピックでの進歩を見ることができれば、きっと感謝します。私たちはそれに対して即時かつ継続的に必要としています。
「いいね！」 1
このスレッドに貢献してくださった皆様に感謝します。この問題が今後のリリースで対応されるのか、あるいは既知の回帰として認識されるのかを丁重にお伺いしたいのです。
現在、enable namesを無効にすると、意図しないと思われる方法で主要な管理機能が壊れてしまいます。これが仕様なのかバグなのかが不明確なため、対応策を立てるのが困難になっています。ユーザー名をフルネームよりも優先する本番サイトを運営している私たちにとって、この制限は現実的な摩擦と予期せぬ動作を引き起こします。
優先順位のバランスを取らなければならないことは理解していますが、これが検討課題に入っているかどうかについて、チームから最新情報が得られると非常に助かります。何か情報を提供していただければ幸いです。
「いいね！」 1
@tobiaseigen さん、この件についてエンジニアリングからのフィードバックはありますか？（3ヶ月経ちましたが、私も他のことで忙しく、この件を追うのを忘れてしまっていたので、文句は言えません。）
今週中にプルリクエストを提出して、会話をより具体的にすることはできますが、レビューされないまま放置されることを懸念しており、また、アプローチに関するいくつかの側面についてフィードバックを得たいと思っています。
編集：明確にするために、Restrict exposure of full name to certain groups - #2 by mdoggydog （enable names を有効にしつつ、フルネームを表示できるユーザーを制御できる機能）の実装に関するプルリクエストについて話しています。
「いいね！」 2
ked
(Kenny DuBose)
35
@RGJ @chrismalone and @mdoggydog こちらでのご意見、本当にありがとうございます。この修正は依然として必要であり、問題に取り組んでいるすべての方々に感謝いたします。
「いいね！」 2
Heliosurge
(Dan DeMontmorency)
36
正直なところ、これがあまり注目されていないことに驚いています。レビューされるかどうか、そして実装されるかどうかわからないのに、PRをすることに慎重になるのは理解できます。
PRはプラグインになるかもしれませんが、そうすると、このオプションはセルフホストに限定されます。
hugh
(Hugh Lashbrooke)
39
@mdoggydog ここでのあなたの解決策は、enable names設定を、グループのリストを受け取る設定に置き換え、メンバーの名前はそれらのグループにのみ表示されるようにすることのようです。
これは、display name on posts設定（および存在する可能性のある他の同様の設定）を尊重する必要があることに注意してください。したがって、許可されたグループであっても、その設定が無効になっている場合は、投稿に名前が表示されません。
さらに、連鎖的な影響として、ここで修正/変更する必要がある他のいくつかのことがあります。
- ユーザープロファイルの管理ビューでは、名前は常に表示される必要があります。これは、設定に関係なく当てはまります。
- 名前は、ユーザーが許可されたグループに属している場合にのみ、メールに表示される必要があります。
上記は、現在の問題を修正するだけでなく、この機能をより柔軟で便利なものにするはずです。
これは、あなたがここで提案していることのように聞こえますか？もしそうなら、このアップデートが含まれたPRを提出していただければ、ぜひ検討させていただきます。
私が書いたコードは、「名前を有効にする」設定を削除するものではありません。 しかし、それに加えています。
full_names_visible_to_groups 設定を追加します（admins と moderators を必須値として含みます）。Guardian に can_see_full_names? メソッドを追加します。これは、enable_names と full_names_visible_to_groups のグループメンバーシップの「and」を実行します。- この新しいメソッドを、サーバーによってフルネームが公開/発行されるすべての適切な場所で使用します。
1と2は簡単でした。3はより複雑で、アドバイス/ガイダンスなしでは解決方法がわからなかったいくつかの問題に直面したことを知っています。コードとメモを深く見直す必要があります。（最後にこれに没頭してから2か月以上経ちました。 
）
（私の記憶が正しければ、「投稿での表示名」などはクライアントサイドの設定であり、サーバーから受信したデータの表示に影響します。つまり、サーバーが出力するものの上に制限が課せられます。）
（1）については、enable_names が true の場合に対応されていると思います。これは、新しいグループごとの設定が利用可能になったら、ほとんどの人が望むものになるでしょう。
（2）については、遭遇し、対処したと思います。
フルネームが漏洩している他のケースもいくつかあったことを覚えています。
いずれにせよ、メモを見直して、今週中にPRを提出し、その過程で未解決の質問/未解決の事柄を掘り起こすつもりです。
「いいね！」 4
hugh
(Hugh Lashbrooke)
41
それは素晴らしいですね！PRへのリンクをこちらに貼ってもらえますか？そうすれば、エンジニアに詳しく見てもらうように手配します。
「いいね！」 6
最初の（2つか3つのうちの）PRはこちらです。
このPRは、後続のPRの前提条件であり、Guardianインスタンスが実際に次のシリアライザーに渡されることを保証します。詳細はPR/コミットメッセージに記載されています。次のPRを準備している間に、このPRに関する議論を開始しても構いません。
私のミニGitHubアカウント冒険
…まあ、編集ボックスにURLを入力するまではそこにありました…そして突然、私のアカウント全体が停止されました。 
再審査請求を提出しました。更新があればお知らせします。
13時間後、私は「時々このようなことが起こります。もう大丈夫です。」という内容のメールを受け取りました。非常にカフカ的でした。私のアカウントはサイトから消えており、数年前にIssue/PRに投稿した投稿さえも消え、私という別の誰かがそこにいたという証拠は、幽霊のような引用ブロックだけが残された、一方的な会話の痕跡となっていました。
これは、アカウントが停止されただけでなく、プロジェクトの履歴の一部が静かに剥ぎ取られたことに対しても、恐ろしく過剰な対応のように思えます。
「いいね！」 3
今回、Discourseプラグインリポジトリの変更の調整も必要になることに気づきました。つまり、テストが常にパスするように（そしてもちろん、mainが常に機能するように）、一種の内側から外側への順序でPR（プルリクエスト）を連鎖させる必要があります。
シーケンスは次のようになると思います（ここで、COREは「discourse/discourseのPR」、PLUGは「公式プラグインリポジトリのPR」を意味します）。
- シリアライザースコープ転送の強制（機能的な変更は予想されません）
a. CORE デフォルトで無効になっているシリアライザースコープチェックを実装
b. PLUG スコープ転送の修正
c. CORE スコープ転送の修正、およびデフォルトでスコープチェックを有効化
- フェーズ4に必要な場所で、先手を打って
Guardians（プレースホルダーを置き換える）を提供する（機能的な変更は予想されません）
- CORE プレースホルダーの修正
- PLUG プレースホルダーの修正
enable_namesのみに依存する単純なGuardian#can_see_full_names?を実装する（機能的な変更は予想されません）
- フルネームが出力される場所で
can_see_full_names?を使用する（必要に応じてenable_namesのむき出しの使用を置き換える）（機能的な変更がある可能性があります）
- CORE 新しい
Guardianメソッドを使用
- PLUG 新しい
Guardianメソッドを使用
full_names_visible_to_groups設定を実装する**（機能的な変更）**
- CORE 設定に新しい設定を追加し、
Guardianメソッドで設定をチェックする
(1)と(2)は、GuardiansがDiscourseコードベース全体でより一貫して確実に使用されるようにすることに帰着します。
(3)と(4)は、バックエンドによってフルネームが公開されるタイミングを制御するための、より正確な抽象概念を確立することです（Guardianが表すコンテキストに応じて公開を決定します）。
(5)は、最終的に（比較的些細な）部分であり、フルネームの公開がグループメンバーシップによって制限されます。
「いいね！」 3
hugh
(Hugh Lashbrooke)
45
ありがとうございます。エンジニアに確認を依頼しました。お考えは正しい方向に向かっているようですが、エンジニアの方がより的確なフィードバックを提供できるかと思います 
「いいね！」 4
ked
(Kenny DuBose)
48
@hugh さん、昇進のために適切な担当者の目に触れるようにしていただきありがとうございます。私たちはしばらくの間、これを待ち望んでいました。
「いいね！」 1
申し訳ありませんが、このPRは却下しなければなりません。この変更は複雑すぎ、保守が困難です。主な理由は以下の通りです。
- スコープは常に必要とは限らず、強制されるべきではありません。
- プラグインなど、すべての場所で変更し、その後保守するのは膨大な作業になります。
PlaceholderGuarianは問題を解決するのではなく、偽のスコープを追加しています（後で修正する意図で）。- ほとんどの場合、シリアライゼーションはコントローラーで行われるべきであり、スコープは自動的に追加されます。
グループに基づいてユーザー名またはフルネームを表示するのは非常に難しいです。これをDiscourseコアにマージしようとする代わりに、プラグインを作成することから始めることはできませんか？コミュニティが小さい場合は、次のように機能します。
「いいね！」 2
元の問題を解決するPRが完了しました。管理者は常にフルネームを確認し、編集できるようになります。来週初めにマージする予定です:crossed_fingers:
「いいね！」 3
enable_names設定が実際に何をすべきかについて、根本的な誤解/意見の相違がまだあると思います。これは次の質問に集約されます。
enable_names設定は、次のいずれかを意味するのでしょうか？
- 「フルネームを公に表示しない。」
- 「このサイトではフルネームを使用しない。」
このトピックでは、一部の人が（1）を意味すると考えており、他の人は（2）を意味すると考えていると思います。私の印象では後者であり、enable_namesはサイトがフルネームを使用するかどうかを決定します。
enable_namesが無効になっている場合を考慮してください。
- サインアップダイアログにフルネームフィールドが表示されません。
- ユーザーは自分のアカウント設定ページにフルネームフィールドを表示せず、ユーザーはどこにも自分のフルネームを表示しません。
管理者のみがシステムにフルネームフィールドが存在することを知っているサイトの使用例が理解できません。私の想像力の欠如により、ここにいる誰もが実際にそれを望んでいるとは信じがたいです。もし誰かがこれを望んでいるなら、私を啓蒙してください！
（私のドラフトPRが何を達成しようとしているのか、どのように、そしてなぜ達成しようとしているのかについても、いくつかの誤解があると思いますが、まずは「enable_namesは何をするのか？」という質問に対処したいと思います。）
「いいね！」 2
RGJ
(Richard - Communiteq)
52
はい、数多くの例を挙げることができます。コミュニティを所有する企業は、顧客の名前を知る法的権利（および/または必要性）を持っていることがよくありますが、プライバシー法により、それらの名前を第三者に公開することは禁じられています。これは、一括メールでCCを使用することがNGであり、BCCを使用する必要があるのと同じような理由です。
さて、これは非常に単純なバグレポートから始まり、単に誤動作していました。そして、私たちは皆、それが何をすべきかについての議論に入り、それが多くの混乱と追加の議論を引き起こしました。それは問題ありませんが、#featureトピックの方が良かったでしょう。
それは#1です。設定の説明には次のように書かれています。
ユーザーのフルネームをプロフィール、ユーザーカード、およびメールに表示します。非表示にするには無効にします。
フルネームが非表示になっているという事実は、それが存在することを意味し、管理者は非表示のものを表示できます。
また、display_name_on_posts、full_name_requirement、およびdisplay_name_on_email_fromもあります。
もしあなたが#2を望むなら、full_name_requirementを基盤として構築し、そこに「Never」というオプションを追加するのがより理にかなっているでしょう。
（そして、はい、enable_namesは別の名前であるべきだということに同意しますが、設定の名前を変更するのは楽しいことではありません）。そして、私も同意します。
これは奇妙です。
「いいね！」 1
Heliosurge
(Dan DeMontmorency)
53
この修正で元の機能は復元されますか？つまり、管理者とユーザーはフルネームを見ることができますか？この変更は当初、元の機能と比較して多くの問題を引き起こしたように思われます。モデレーターであっても、特定のケースでは望ましい場合や必要な場合があるため、設定によって実際の名前を確認できるオプションを持つべきです。
チームがこの変更をプッシュした後、実名を入力していたユーザーはすべて空白になりました。
この設定は、明確な定義を持つ2つの設定に分離されるべきだったと思います。名前を無効にする新しい機能は、実名をオフにする新しい設定として追加されるべきでした。
私は幸いにも小さなコミュニティを持っています。数千人のメンバーがいるサイトで、彼らの実名が空白になったと想像してみてください。