皆さん、こんにちは。
管理しているフォーラムでは、ユーザー名にはかなりの自由度を与えていますが、利用規約で、ユーザーは氏名を記載し、法的な氏名変更を反映する場合を除き、変更しないことを要求しています。まだユーザーは多くありません（250人未満）が、すでにこのルールを守らない人が出てきています。そのため、このルールを強制する方法が必要です。
要するに、アカウントが承認された後にのみ、モデレーターまたは管理者が氏名を変更できるようにする必要があります。Discourseでこれを達成する方法はありますか？ドキュメントを調べましたが、見つかりませんでした。
もしなければ、この機能をコードに追加することはできますか？
よろしくお願いします。
簡単な回避策は、CSS で編集ボタンを非表示にすることです。しかし、賢い人はそれでも編集できます。それを維持するには、プラグインまたは SSO が必要になるでしょう。
お返事ありがとうございます。そのようなプラグインはすでに存在するかどうかご存知ですか？もし存在しない場合は、これを理解しようとしますが、最後に何かをコーディングしてからずいぶん経ちました:frowning:
プラグインが存在しないようですが、CSSの回避策として、FirefoxまたはChromeの「要素を調査」機能を使用して非表示にしたいボックスをクリックし、テーマのCSSを編集します。
外部認証プロバイダー（OAuthなど）を使用し、「auth overrides username」オプションを有効にするのがここでの最善の選択肢だと思います。
ログインごとにローカルの氏名を外部サイトの氏名で上書きし、ローカルでの変更を防止します。すべての認証プロバイダーに適用されます。
それはうまくいきますが、サードパーティのサービスを含めることは、ユーザーが自分のメールプロバイダーを選択できるようにすることに満足している多くの人々にとって、あまり良い取引ではありません。
「外部」とは、「サードパーティ」ではなく、「Discourseの外部」を意味します。サードパーティのソリューションを使用することもできますし、自分で実行することもできます。
私たち自身の信頼は、すべてを構築したトップクラスのプロフェッショナルであるDiscourseコアチームを信頼することとは異なります。
私の言いたいのは、あなたの最も強力な解決策は、スイッチからオプションを無効にすることほどエレガントではないということです。
こんにちは。
ご提案ありがとうございます。しかし、残念ながら現時点ではそれは選択肢ではありません。中央SSOがなく、その管理は私が望む以上のものです！
現在、CSSの改変が、私がどこまでできるかの限界でしょう。私が管理しているのはクラブフォーラムであり、すべてのメンバーが特定されています。この変更を強制することは、無効にされている（そしてルールで禁止されている）だけであっても、ユーザーのアカウントを読み取り専用に変換するか、完全に無効にする原因となります。
提供していただいたリンクをありがとうございます、@satonotdead。このコンテンツを閲覧し、変更を簡単に管理できるかどうかを確認します。長期的な視点では、時間があるとき（退職まで15年以上待つ必要があるかもしれません:sweat_smile:）、プラグインを作成することに投資するかもしれません…
ハイブリッドソリューションでうまくいくでしょうか @AriesFR？
Jay @pfaffman の CSS で隠すという提案を採用し、カスタムユーザーフィールドを作成して、設定を次のようにするとどうでしょうか。
確かに機能するかもしれませんが、現在の氏名と同様に、ユーザー名の横に表示させたいです。
とりあえず、ユーザーのプロフィール更新セクションから氏名セクションを非表示にすることが、一時的な解決策としては問題ないでしょう。それでも、詮索好きなユーザーからの例外は処理できます。
ユーザー名と同様に、このロックオプションを基本製品に含めることがなぜそんなに問題になるのか、まだ理解できません。非常に教条的であるように思えます。
[からかいモードON]
ユーザー署名を許可しないのは、我々のためだ、というようなものですね。
[からかいモードOFF]
確認しましたが、API を使用してフィールドを非表示にすることはできますが、そのユーザーが承認されているかどうかを知るための信頼できるデータが見つかりません（設定ページのコンテキストで）：thinking:
これが今のところの私の進捗です。
罪悪感を感じるべきかどうかわかりません。少しハッキーかもしれませんが。 
<script type="text/discourse-plugin" version="0.8">
const { setting } = require("discourse/lib/computed");
api.modifyClass("controller:preferences/account", {
pluginId: "hide-name-in-preferences",
get canEditName() {
const enables_name = setting("enable_names");
if (enables_name && this.isCurrentUser && !this.model.staff) {
if (this.model.name) {
// 入力フィールドのみを非表示にする（名前は表示される）
this.model.can_edit_name = false;
} else {
// セクション全体を非表示にする
return false;
}
}
return enables_name;
},
});
</script>
問題でも教条主義でもありません。ほとんどの機能は需要に基づいて優先順位が付けられていますが、これに対する需要はあまりありませんでした。
@Arkshineさん、ありがとうございます。まさに求めていたものに近いようです。環境に組み込む方法を調べる必要がありますが、おそらく今週末までには組み込めるでしょう 
ありがとうございます。優先順位付けは理解できますが、グローバルメカニズムはすでに存在しており、私の見たところでは、ユーザーから複数回リクエストされているようです。もしパッチがArshkineさんが提供してくれたものと同じくらい単純なのであれば、他のフィールドと同じ「配慮」をこのフィールドに与えないという意図的な選択だったように思えます。
誤解しないでください。これはここで開発された素晴らしいソフトウェアです。私が管理を手伝っているフォーラムから判断する限り、それは完璧に機能しているように見えますし、それがどれほど難しいかはわかっています。ただ、すべての決定に同意するわけではなく、与えられた正当化の一部は、時に教条的または権威主義的であると考えています。それでも、今日利用可能な中で最高であることに変わりはありません。
Cheers
テーマコンポーネントは、セーフモードを使用するか、ブラウザ内のものを変更することで回避できます。
主に、CDCK/Discourse.orgでホストされている人々によって開発が進められています。そこから収益が生まれるからです。多くの人が機能を欲しがったり必要としたりする場合に機能が追加されることもありますが、CDCKにお金を払っていない人々の場合、非常に多くの人が必要とするか、多くの有料顧客が喜んで受け入れると思われる機能である必要があります。私は彼らのために働いているわけではないので、これは過去約8年間の私の観察にすぎません。
その通りです！管理職以外のユーザーが使用できないように、セーフモードを有効にする 設定を無効にすることをお勧めします。
おお！それには気づきませんでした。ブラウザの開発者コンソールを巧みに使える人なら、それでも回避できます。
ありがとうございます。このパラメータに気づきませんでした。無効にしました！
推測ですが、これを望んでいて、かつ有料顧客である人のほとんどは、すでに何らかの SSO を利用している可能性が高いのではないでしょうか。そうなると、それ以外のすべての人にとって、さらにニッチな機能になってしまいます。
ユーザーがサインアップ時に提供するフルネームの認証を行っていないように思われます。もしBob JonesからSam Smithに変更された場合、どちらの名前が本人であるかをどのように判断するのでしょうか？