問題ありません！disallowed_groups が役立つことを嬉しく思います。その PR は今マージしました。
これで disallowed_groups と resolve_group_memberships が利用可能になったので、すべての公式テーマとコンポーネントを見直す必要があります。あなたと @moin も、各自のテーマとコンポーネントで同様の作業を行えるようにしてください。公式リポジトリに変更を加えた後、OP で提案された変更を stable に進めることを強く希望しているためです。
現在、他の多くのコア機能で anonymous_users や logged_in_users に依存して使用されており、everyone グループを削除したいと考えています。
やあ、マーティン。質問です：
さっきインスタンスのフルアップデートを実行したばかりで、今、こちらの自動グループIDに基づいて everyone と anonymous_users の disallowed_groups オブジェクト設定をコンポーネントに追加しています：
こんな感じです：
groups:
type: groups
disallowed_groups: "0|4"
required: true
resolve_group_membership: true
validations:
max: 20
しかし、コンポーネントのグループドロップダウン設定に everyone がまだ表示されています：
オブジェクト設定で何が間違っているのでしょうか？ disallowed_groups をオブジェクトから削除しても、anonymous_users グループは表示されないことに気づきました（つまり、現時点では disallowed_groups を設定しようがしまいが、コンポーネント内のリストに違いはありません）。他のグループIDでも試してみましたが、disallowed_groups の使い方（または構文）で何か間違っているようです。なぜなら、どのIDを使っても効果が全く見られないからです。
本日早些时候出现了一些 GitHub 问题，因此 disallowed_groups 的更改刚刚才合并到最新的 Commits · discourse/discourse · GitHub 中。
我不完全确定这就是问题所在，但你能否尝试再次更新，看看问题是否仍然存在？如果没有，请告诉我，并指引我查看你的主题组件（或者只是你的群组侧边栏组件？），以便我进行调试 
おそらく、テストに使用したフォーラムで今後の変更が無効化されていたためです。有効化しましたので、今では表示されています。
everyone と anonymous_users は期待通りに非表示になっています。
念のため補足しますが、2週間ほど前にその変更を無効化したのは私です 
はは 
Moinさん、ありがとう！ 実は、新しい粒度のグループ設定が本来次のアップデートで入る予定だったことを忘れていました。
Martinさん、disallowed_groups オブジェクト設定は完璧に動作します。この変更は本当に気に入りました。チーム、またしてもありがとう。素晴らしい改善ですね。
匿名ユーザーと登録ユーザーのCSSクラス名を教えてください。純粋なCSSを使用しているため、内部IDは使用していません。
デフォルトではこれらの CSS クラスを body 要素に追加しません。CSS Classes for Current User's Groups を指していますか？
このコンポーネントは、現在ログインしているユーザーがいるかどうかに応じて、group-anonymous または group-logged-in-users を追加するように更新する必要があります。
やっほー、マーティン 
anonymous_users と logged_in_users の2つのクラスを追加するためのクイックPRを作成しました。
実際にテストしたわけではありません（笑）が、かなり straightforward（直感的）だと思います。このコードは現在のユーザーが存在するかをチェックし、存在する場合は logged_in_users のメンバーとして、存在しない場合は anonymous_users として扱います。
注: Discourse は自動的に .anon を追加しているので、匿名ユーザーとログイン済みユーザーのCSSはコンポーネントなしでも実現できますが、これは単に新しいグループの慣習を使用しているだけです。
ああ、その通りですね。以前は <body> タグしか見ていなかったので気づきませんでした。
とにかく、そのプラグインの PR は承認しました。問題ないと思います
みんなのために念のため、私はまだここには投稿していませんでしたが、公式コンポーネントが resolve_group_membership と disallowed_groups を使用するようにこれらの PR をマージしました：
この間もなく行われる変更の次のステップに関する計画を立てています。コア/プラグインのコードベースには、まだ everyone を直接参照していたり、サーバーサイドで user.in_any_groups? を使用していない箇所が残っているようです。
なぜまだマージされていないのでしょうか？
このトピックを作成した理由は、ついにコンポーネントを更新したからです。
[quote=“martin, post:14, topic:402273”]
テーマコンポーネントで default_favorite_filters_groups のデフォルト値を 0 (everyone) ではなく 4|5（ログイン済みユーザーと匿名ユーザー）に変更することをお勧めします。0 (everyone) はまもなく廃止される予定です。
[/quote]\n私はそのように変更しました。しかし、この変更は、私が設定を変更した後にコンポーネントを追加したフォーラムでのみ有効に思えます。すでに使用しているフォーラムでは、新しいデフォルト値は適用されません（これは通常は良いことです）。そのため、すでにコンポーネントを使用しているユーザーにとって、予期せぬ動作の変化という問題が残っているように見えます。
また、管理者が私がアップデートで禁止グループとして追加したグループで設定を構成していた場合、どうなるかご存知ですか？
このコンポーネントが多くのフォーラムで使用されているとは考えていないため、あまり心配せずにマージしましたが、マイグレーションと禁止グループの設定は、他のテーマ開発者にとっても関連する可能性があります。
いいえ、何故か私の脳がこれを Discourse 組織の PR だと思っていないと勘違いしていました 
CI チェックが実行されたらすぐにマージします。
このような場合や将来の他のケースにおいて、おそらく最善の方法は、テーマ/コンポーネントごとにマイグレーションを作成することだと思います Migrate Discourse theme settings
上記の投稿で、いつこれを実施すべきかという質問をしました。新しいグループがすべてのフォーラムで正常に動作するか確認せずに移行すると、システムが破損する可能性もありますし、管理者は変更をオン/オフで切り替えることができます。そのため、適切なタイミングで移行することは不可能に思えます。
すでに言及されていた場合、見落としていたかもしれません… ごめんなさい。
resolve_group_membership が設定に含まれている場合、user_in_ プレフィックスを介してブール値にのみアクセスでき、設定フィールドの生値にはもはやアクセスできないことに気づきました。
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true または false
これは意図的な動作でしょうか？
そうだと思います。そうでなければ、このバグの解決策は違っていたかもしれません。
私にもその理屈は納得できます。user_in_x は、フロントエンドが認識していないグループ（管理者のみが閲覧可能なグループや、デフォルトで表示が制限されている everyone のようなグループ）もチェックするためです。そのため、使用するメソッドによって結果が異なることになり、これらを組み合わせると予期せぬ影響が生じる可能性があります。
Moinさん、ありがとうございます。その通りです。@gormus 実際のグループIDが依然として表示されるのは、テーマ設定の管理者UIのみです。
以前投稿した内容から明確かどうかはわかりませんが、anonymous_users と logged_in_users は、この今後の変更を有効にしなくてもいつでも使用可能です。これらは数か月前に独立して追加しました。この今後の変更の主な内容は以下の通りです。
したがって、いずれにせよ、everyone の使用箇所をすべて削除し、今後は anonymous_users と logged_in_users のみを使用すれば、安全です。
本日、サイト設定から everyone を完全に削除するために残っている作業の計画を立てる予定です（カテゴリ設定については当面触れません）。その計画をここに投稿しますので、これにより今後の進捗を共有しやすくなり、進めながらこの計画を更新していけることを期待しています。
ただし、この変更が無効化されている場合、これらのグループはインターフェースに表示されません。管理者はこれらのグループに対して設定を変更することができません。そのため、「everyone」を disallowed_group に追加すると、訪問者に対してコンポーネントを表示させることを許可するグループが一切見えなくなります。私にとって「利用可能」とは、単に機能するだけでなく、表示されることを意味します。この変更を無効化することが依然として可能であるため、新しいグループのみを依存先とすることを「安全」とは呼びません。
うーん、その通りですね。この disallowed_group の問題を解消するためには、今後の変更が無効化されている場合に、他にもいくつか修正が必要な点があります。
anonymous_users と logged_in_users はグループセレクターに一切表示されていません。ここでこれらを許可しても問題ないと思います。そうすれば、今後の変更がオフになっている場合、everyone を disallowed_groups に追加していても影響が出なくなります。anonymous_users を正しく処理するように Guardian::AnonymousUser#in_any_groups? を修正します。0 (everyone) から 5 (logged_in_users) への読み取り時間のエイリアシングを追加します。また、今後の変更がまだオプションであり、無効化されている間は、グループセレクターで everyone に (legacy) のマークを付けるかもしれません。
これらのタスクを優先順位付けし、現在作成中の全体計画に追加します。
こちらで専用のトピックを作成しました @moin The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions 。最初の投稿はまだ未完成で、ローカルですべてのケースを確認中です。随時更新していきます。このトピックで引き続き投稿していただいても構いませんが、可能な限り新しいトピックで議論を進めていただければ幸いです。そうすれば、最初の投稿の一部を引用したり、必要に応じて追加したりしやすくなるためです。
ちょっと待って、これを見てしまいました。
つまり、一部の人が「everyone（全員）」がログイン済みユーザーのみを指すのかと混乱していた、ということですか？
誰が？！
everyone は everyone ですよね。非常に明確です。
everyone は、ログインしていてもいなくても、サイトを訪れるすべての人を指すはずですよね。これは単純なことではありませんか？
それでは、完全にパブリックな Category には、今後は「ログイン済み」と「匿名（anon）」の2つのグループが必要になるということですか？1つではなく2つに？それはばかばかしく、アップグレードとは言い難いですよね。
もしそうではなく、「anon」は「everyone」の同義語なので、そのように設定すればよい、ということなら、それはもう正確ではありません。ログイン済みユーザーは anon ではないからです。
Discourse に関してある種の「学習」が必要だった点として、TL0 が場合によっては「アカウントを持ち、ログインしているすべての人」を指す一方で、「まだ TL1 に到達していないが、アカウントを持ち、ログインしている人」を指すこともあった、という点があります。
ここでのポイントは、TL0 が単一のグループを代表するのではなく、閾値（threshold） を代表していたことです。これが鍵でした。
TL0 を単に「ログイン済みユーザー」に変更することで、各セキュリティレベルが閾値であるという一貫性が崩壊します。TL1 もまた閾値であり、厳密には「単一のグループ」ではありません。では、それなら「少なくともトラストレベル1のログイン済みユーザー」というグループが必要になるということですか？！
私はこれらの変更が本当に必要だったとは全く思いません。変更のための変更ですか？