匿名ユーザーとログインユーザー向けのグループベースのきめ細かい権限

ニュースとイベント お知らせ
1

私たちのコードベースには、歴史的に混乱を招いてきた @everyone という疑似グループが存在しており、以下に使用されます：

  • group_list 型のサイト設定
  • カテゴリの権限
  • タググループ

一部のケースでは、人々は @everyone を「すべての匿名ユーザーおよびすべてのログイン済みユーザー」と解釈していますが、他の人々は「すべてのログイン済みユーザー」のみを指すと解釈しています。実際のところ、サイト設定においては、多くの場合「すべてのログイン済みユーザー」のみを意味します。

さらに混乱を招いているのは、pm_tags_allowed_for_groups のような設定において、「すべての匿名ユーザーおよびログイン済みユーザー」が機能にアクセスすることが理にかなっていないにもかかわらず、この @everyone グループが使用可能であるという事実です。

また、機能フラグ付けや開発者体験の観点からも混乱を招いています。今後予定されている変更や他の設定において、真に「すべての匿名ユーザーおよびログイン済みユーザー」に対して有効にしたい場合があるためです。

解決策

私たちは、2 つの独立した自動疑似グループを導入します：

  • anonymous_users (ID 4) - アカウントを持たずにサイトを閲覧する匿名ユーザーを表します
  • logged_in_users (ID 5) - サイトにログインしているすべてのユーザーを表します。効果としては trust_level_0 自動グループと似ていますが、より具体的です

これらはすでに導入されていますが、サイト上で granular_anonymous_and_logged_in_groups_permissions という予定されている変更が有効化された場合にのみ機能します。

予定されている変更が有効化されると、グループとして everyone が選択されているすべての設定は、自動的に logged_in_users ID に変換されます。そのため、予定されている変更の切り替え時にサイト設定テーブル内のデータは変更されません。予定されている変更が恒久的なものになった段階で、すべてのグループ設定に対してこの変更を行うデータ移行を実施します。

さらに、personal_message_enabled_groups のように、匿名ユーザーのアクセスが理にかなっていないいくつかのサイト設定において、anonymous_users を disallowed_group としてマークしました。

image
image1217×205 51.6 KB

既存のグループ名との競合は、既存のグループの名前を変更し、投稿内のグループメンションを更新することで自動的に処理されます。

タグおよびカテゴリの権限についてはどうなりますか？

これらの権限は変更されません。なぜなら、それらの「everyone」の概念はいくつかの点で異なり、基礎となる自動グループに依存していないためです。

「いいね！」 9
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

ちょっと待って… 何 :flushed_face: それって、その設定が有効になった時点で、現在「全員（everyone）」として公開されているすべてのカテゴリが、ログインが必要な「クローズド」カテゴリに自動的に切り替わるってことですか？

4

いいえ、なぜなら：

これは現在、「全員」を選択できるグループリストタイプのサイト設定にのみ影響します。以下のように：

image
image909×273 54 KB

「いいね！」 1
5

テーマコンポーネントの調整方法を教えていただけますか？

copy-post コンポーネントを例に試してみました。このコンポーネントも、機能へのアクセスを許可するグループ設定を使用していたことを覚えているからです。また、「everyone」疑似グループには個別のチェックが必要だったという問題 がありました。私のコンポーネントと同様に、ユーザーが所属するグループの ID を比較するだけでは不十分で、それらの ID は個別に確認する必要があるためです。そのため、最近の変更があったのではないかと期待していました。私の理解では、新しいグループも疑似グループであり、ID を個別に確認する必要があるからです。なぜここではそれが不要なのかを説明する何かを見落としているのでしょうか？

私の favorite filters コンポーネントには、2 つのグループ設定があります。1 つはグループが独自のフィルターを保存できるようにする設定、もう 1 つは標準フィルターを提供する設定です。
デフォルトでは、trust_level_0 グループのメンバーのみがカスタムフィルターを使用できます。これは、カスタムユーザーフィールドにデータを保存できるのは登録ユーザーのみだからです。したがって、ここでは anonymous_users を選択できないようにするのが妥当です。テーマコンポーネントでこれをどのように実現すればよいでしょうか？すでに例はありますか？

デフォルトフィルターのデフォルト設定は「everyone」です。未登録ユーザーでもデフォルトフィルターを表示して使用できるようにすることが役立つと考えているためです。問題は、私が明示的に「everyone」を選択しているにもかかわらず、everyone が logged_in_users に変更されてしまうことです。このため、現在 everyone を使用している管理者が将来も未登録ユーザー向けのフィルターを維持できるよう、カスタムマイグレーションを作成する必要がありますか？このマイグレーションはいつ実行する必要がありますか？あるいは、マイグレーション実行後にすべての管理者が個別に変更を行う必要があるのでしょうか？

私が懸念していることは、実際には不要なのでしょうか？調整が必要な場合、4 週間未満という期間は、潜在的に影響を受けるコミュニティ維持コンポーネントの数を考えると、かなり短いと感じます。
「copy-post」に加えて、unanswered filter コンポーネント も確認しましたが、そこにも変更は見つかりませんでした。重要な何かを見落としているような気がします。結局のところ、この変更はほぼ 1 週間前からデフォルトで有効になっています。そのため、調整が必要な場合、公式コンポーネントはすでに更新されているはずだと推測しています。

「いいね！」 1
6

3件の投稿が既存のトピックに統合されました：Foundationテーマの近代化

7

これらのコンポーネントを見ると、currentUser?.groups はそもそも信頼できません。なぜなら、これはユーザーに「表示される」グループのみを含み、権限に影響を与えるグループがここでシリアライズされていない可能性があるからです。

コアやプラグインでは、現在のユーザーシリアライザーで以下のような処理を行うことでこの問題を回避しています。

ただし、明らかにこれはテーマコンポーネントやテーマ、およびそれらの設定には利用できません。

うーん、確信が持てません。よく考えてみましょう。もし本当に everyone を意図していたのであれば、logged_in_users と anonymous_users の両方に変更する必要があります。これが OP で述べられた everyone の主な問題点でした。ある人はログインユーザーのみを意味すると解釈し、別の人はログインユーザー＋匿名ユーザーを意味すると解釈し、状況に大きく依存していたのです。

セキュリティの観点からより安全だったため、私は「ログインユーザーのみ」という解釈を選びました。

いいえ、テーマコンポーネントやテーマ、およびそれらの設定がどのように影響を受けるかについて考えが及んでいませんでした。私は主にサイト設定に焦点を当てていました。このような問題は特に発見するのが非常に難しいでしょう。なぜなら、AUTO_GROUPS 定数さえも使用していないからです。

image

とにかく、これらの問題に対するいくつかの解決策を考え出します。それらが解決されるまで、この変更を Stable ブランチに移行することはありません。

「いいね！」 3
Introducing Upcoming Changes, a system to manage new features and changes to existing functionality in your community
9

クイックアップデートですが、この問題の対処法についてアイデアがあり、現在内部で検討中です。それほど時間はかからないはずです :crossed_fingers:

「いいね！」 1
10

This is exactly me :upside_down_face:; so in order to create a category for registered users only, I set its access permission to TL0 only, relying on the TL0 automatic user group to distinguish logged-in users from guests.

I wonder if there is a table for distinguishing the meaning of this term in different contexts. Such differences are both confusing and unsettling—because when people originally chose this setting, they probably didn’t know its actual meaning, so they would want to check the related settings. Currently, I can only check each place where groups are set individually, and confirm what it used to mean by seeing who it was changed to after the Granular group feature was enabled—which feels like fumbling in the dark.

「いいね！」 2
11

これは良いアイデアです…AIを使って、グループベースの設定が使用されているすべての場所を調べて、anonymousがそれらにアクセスできるかどうかを出力できるかもしれません。

anonymous_usersグループの選択を既に禁止している設定がいくつかあるので、それらが良い出発点になるでしょう…調査結果をここで報告します。

これについてのPRを現在作成しています：

後続のPRとドキュメントの変更もすぐに提供します。

「いいね！」 3
12

@Noble_Fish これは、グループベースの設定のAI生成リスト、各設定の目的、および匿名ユーザー/ログイン済みユーザーがその設定にどのように適用されるかを示したものです。私はこれが概ね正しいとかなり確信していますが、AI生成物にありがちなこととして、事実関係はご自身で再確認することをお勧めします。

最も興味深い列は「変更前に everyone は anonymous_users も含まれていたか？」です。これが「はい」の場合、この変更が適用される前は everyone がログイン済みユーザーと匿名ユーザーの両方を意味していたことを示します。

ご覧の通り、該当する設定は数えるほどしかありません。したがって、管理者がサイト設定で明示的に anonymous_users を追加する必要があるのはこれらの設定のみです：

  • hidden_post_visible_groups - この設定については、anonymous_users を許可するように変更する必要があります。現在のコードはこの変更に対応していません。
  • lazy_load_categories_groups - これも修正が必要です。user.in_any_groups? 内部ですでに行われている everyone のチェックを冗長に実行しています。
  • styleguide_allowed_groups - 現状のままだと動作しますが、これも少し調整します。

この変更が恒久的になると、logged_in_users と anonymous_users のグループが排他的に使用され、everyone は削除されます。

設定 説明 logged_in_users が適用される？ anonymous_users が適用される？ 変更前に everyone は anonymous_users も含まれていた？ コードの該当箇所
whispers_allowed_groups 指定されたグループのメンバーがトピック内でプライベートな通信を行えるようにします。 いいえ いいえ いいえ everyone、logged_in_users、anonymous_users は禁止されています。ランタイムは具体的なグループメンバーシップを期待しています。
hidden_post_visible_groups これらのグループのメンバーが非表示の投稿を表示できるようにします。スタッフユーザーは常に非表示の投稿を表示できます。 はい いいえ はい 匿名ユーザーを拒否する前に everyone をチェックします。それ以外は in_any_groups? を使用します。
about_page_hidden_groups /about ページに特定のグループのメンバーを表示しません。 いいえ いいえ いいえ group_users を使用します。擬似グループにはメンバー行がありません。
about_page_extra_groups モデレーターの下に「About」ページに表示するグループ。 いいえ いいえ いいえ 表示のために具体的なグループとメンバーをロードします。
anonymous_posting_allowed_groups 匿名投稿を有効化できるグループ。 はい いいえ いいえ in_any_groups? によるログイン済みユーザーのゲートチェック。anonymous_users は禁止されています。
personal_message_enabled_groups これらのグループのユーザーがパーソナルメッセージを作成できるようにします。 はい いいえ いいえ in_any_groups? によるログイン済みユーザーのゲートチェック。anonymous_users は禁止されています。
shared_drafts_allowed_groups これらのグループのユーザーが共有下書きを表示・編集できるようにします。 はい いいえ いいえ Guardian（権限チェック）によるユーザーゲート。anonymous_users は禁止されています。
here_mention_allowed_groups @here をメンションできるグループ。 はい いいえ いいえ 認証済みユーザーが必要です。anonymous_users は禁止されています。
approve_unless_allowed_groups これらのグループに属さないユーザーの投稿は承認が必要です。 はい いいえ いいえ in_any_groups? によるユーザーゲート。anonymous_users は禁止されています。
approve_new_topics_unless_allowed_groups これらのグループに属さないユーザーが作成した新しいトピックは承認が必要です。 はい いいえ いいえ in_any_groups? によるユーザーゲート。anonymous_users は禁止されています。
skip_review_media_groups これらのグループ以外のユーザーは、埋め込みメディアを含む投稿がレビューに送られます。 はい いいえ いいえ in_any_groups? によるユーザーゲート。anonymous_users は禁止されています。
content_localization_allowed_groups ローカライズされたコンテンツを更新できるグループ。 はい いいえ いいえ Guardian/ユーザーゲート。anonymous_users は禁止されています。
email_in_allowed_groups メール経由で新しいトピックを投稿できるグループ。 はい いいえ いいえ メール送信者によるユーザーゲート。anonymous_users は禁止されています。
view_raw_email_allowed_groups 受信メールの生データを表示できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
uploaded_avatars_allowed_groups カスタムプロフィール画像のアップロードを許可するグループを指定します。 はい いいえ いいえ 現在/対象ユーザーによるゲートチェック。anonymous_users は禁止されています。
create_topic_allowed_groups 新しいトピックを作成できるグループ。 はい いいえ いいえ ユーザーが必要で in_any_groups? を使用します。anonymous_users は禁止されています。
topic_timers_allowed_groups トピックタイマーを設定できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
edit_wiki_post_allowed_groups ウィキとしてマークされた投稿を編集できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
edit_post_allowed_groups 投稿を編集できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
self_wiki_allowed_groups これらのグループのユーザーが自分の投稿をウィキ化できるようにします。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
send_email_messages_allowed_groups メール経由でパーソナルメッセージを送信できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
flag_post_allowed_groups 投稿にフラグを立てられるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
post_links_allowed_groups 投稿にリンクを含められるグループ。 はい いいえ いいえ 認証済みユーザーが必要です。anonymous_users は禁止されています。
embedded_media_post_allowed_groups これらのグループのユーザーは投稿にメディアアイテムを埋め込めます。 はい いいえ いいえ 操作中のユーザーによるゲートチェック。anonymous_users は禁止されています。
profile_background_allowed_groups プロフィール背景をアップロードできるグループ。 はい いいえ いいえ ユーザーゲート。anonymous_users は禁止されています。
user_card_background_allowed_groups ユーザーカードの背景をアップロードできるグループ。 はい いいえ いいえ ユーザーゲート。anonymous_users は禁止されています。
invite_allowed_groups ユーザーを招待できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
ignore_allowed_groups 他のユーザーを無視できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
delete_all_posts_and_topics_allowed_groups 他のユーザーが作成した投稿やトピックを削除し、削除されたコンテンツを表示できるグループ。 はい いいえ いいえ Guardian/現在ユーザーによるゲートチェック。anonymous_users は禁止されています。
edit_all_topic_groups このグループのユーザーが他のユーザーのトピックタイトル、タグ、カテゴリを編集できるようにします。 はい いいえ いいえ 生の分割処理後、in_any_groups? を使用。anonymous_users は禁止されています。
edit_all_post_groups このグループのユーザーが他のユーザーの投稿を編集できるようにします。 はい いいえ いいえ in_any_groups? によるユーザーゲート。anonymous_users は禁止されています。
change_post_ownership_allowed_groups これらのグループのユーザーが投稿の所有者を変更できるようにします。 はい いいえ いいえ 現在ユーザーによるゲートチェック。anonymous_users は禁止されています。
cross_origin_opener_unsafe_none_groups 非表示のCOOPオーバーライドグループ。一致するユーザーは Cross-Origin-Opener-Policy: unsafe-none を取得します。 はい いいえ いいえ current_user.present? が必要です。匿名の選択にはランタイムでの効果はありません。
user_api_key_allowed_groups ユーザーAPIキーの生成に必要なグループメンバーシップ。 はい いいえ いいえ 現在ユーザーによるゲートチェック。anonymous_users は禁止されています。
create_tag_allowed_groups タグを作成できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
edit_tags_allowed_groups タグ、タグの説明、タグの同義語を編集できるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
tag_topic_allowed_groups トピックにタグを付けられるグループ。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
pm_tags_allowed_for_groups 含まれるグループのメンバーが任意のパーソナルメッセージにタグを付けられるようにします。 はい いいえ いいえ Guardianによるユーザーゲート。anonymous_users は禁止されています。
lazy_load_categories_groups カテゴリ情報をこれらのグループのユーザーのみで遅延ロードします。 はい はい はい 明示的な everyone チェックとGuardianの in_any_groups?。anonymous_users は意味を持ちます。
chat_allowed_groups これらのグループのユーザーはチャットできます。ただし、この設定に追加された匿名ユーザーはチャットのみ閲覧可能です。 はい はい いいえ ログイン済みチャットは in_any_groups? を使用します。匿名の公開チャットは anonymous_users を明示的にチェックします。
direct_message_enabled_groups これらのグループ内のユーザーがユーザー間パーソナルチャットを作成できるようにします。 はい いいえ いいえ ログイン済みチャットのGuardianゲート。意味のある匿名DMパスはありません。
chat_pinning_messages_allowed_groups これらのグループのユーザーはチャットメッセージをピン留めできます。 はい いいえ いいえ チャットアクセス/現在ユーザーが必要です。匿名のピン留めパスはありません。
chat_message_flag_allowed_groups これらのグループのユーザーはチャットメッセージにフラグを立てられます。 はい いいえ いいえ ユーザーゲート。匿名パスは周囲のチャット権限によってブロックされます。
no_ads_for_groups これらのグループのユーザーには広告を表示しません。 はい いいえ いいえ current_user シリアライザーにのみ追加されます。匿名の現在ユーザーペイロードはありません。
adsense_exclude_groups これらのグループのメンバーには広告が表示されません。 はい いいえ いいえ in_any_groups? による現在ユーザーの広告フラグ。匿名の現在ユーザーペイロードはありません。
dfp_exclude_groups これらのグループのメンバーには広告が表示されません。 はい いいえ いいえ in_any_groups? による現在ユーザーの広告フラグ。
amazon_exclude_groups これらのグループのメンバーには広告が表示されません。 はい いいえ いいえ in_any_groups? による現在ユーザーの広告フラグ。
carbonads_exclude_groups これらのグループのメンバーには広告が表示されません。 はい いいえ いいえ in_any_groups? による現在ユーザーの広告フラグ。
adbutler_exclude_groups これらのグループのメンバーには広告が表示されません。 はい いいえ いいえ in_any_groups? による現在ユーザーの広告フラグ。
composer_ai_helper_allowed_groups これらのグループのユーザーは、コンポーザーにAIヘルパーボタンが表示されます。 はい いいえ いいえ in_any_groups? によるログイン済みAIヘルパーゲート。
post_ai_helper_allowed_groups 投稿でAIヘルパー機能にアクセスできるユーザーグループ。 はい いいえ いいえ in_any_groups? によるログイン済みAIヘルパーゲート。
ai_pm_summarization_allowed_groups PM（パーソナルメッセージ）で要約を作成・表示できるグループ。 いいえ いいえ いいえ 生の user.group_ids を使用するため、擬似グループは一致しません。
ai_bot_debugging_allowed_groups これらのグループに、生のAIリクエストとレスポンスを表示するデバッグボタンを表示できるようにします。 はい いいえ いいえ 匿名に対して明示的に false を返した後、in_any_groups? を使用します。
ai_bot_allowed_groups GPTボットがPMにアクセスできる場合、これらのグループのメンバーに返信します。 はい いいえ いいえ 主要なゲートは in_any_groups? を使用します。プレイグラウンドパスの1つは生の group_ids を使用します。
ai_bot_public_sharing_allowed_groups これらのグループが、ユニークなリンクを介してAIパーソナルメッセージを公開できるようにします。 はい いいえ いいえ 匿名に対して明示的に false を返した後、in_any_groups? を使用します。
assign_allowed_on_groups これらのグループのユーザーはトピックを割り当てられます。 いいえ いいえ いいえ 生の user.group_ids/GroupUser を使用します。擬似グループには行がありません。
discourse_post_event_allowed_on_groups イベントを作成できるグループ。 いいえ いいえ いいえ 生の groups.where(id: ...)。everyone は特別処理されますが、logged_in_users は処理されません。
discourse_kanban_manage_board_allowed_groups カンバンボードを作成・設定できるグループ。 はい いいえ いいえ Guardianは in_any_groups? を使用しますが、書き込みコントローラーはログインを必要とします。
create_policy_allowed_groups 投稿にポリシーを追加するためのグループメンバーシップが必要です。 はい いいえ いいえ 投稿/ユーザーゲートは in_any_groups? を通じて行われます。
flag_posts_voting_comments_allowed_groups 投稿の投票コメントにフラグを立てられるグループ。 はい いいえ いいえ in_any_groups? によるユーザーゲート。
allow_solved_in_groups これらのグループのグループメッセージで解決済みとしてマークできるようにします。 ユーザーゲートなし ユーザーゲートなし ユーザーゲートなし 現在ユーザーのメンバーシップではなく、PMの topic.allowed_groups に一致します。
accept_all_solutions_allowed_groups 任意のトピックで解決策を受け入れられるグループ。 はい いいえ いいえ in_any_groups? による認証済み/現在ユーザーゲート。
discourse_templates_groups_allowed_private_templates プライベートテンプレートを使用できるグループ。 いいえ いいえ いいえ 生の GroupUser.exists?。everyone のみが特別処理されます。
poll_create_allowed_groups 投票を作成できるグループ。 はい いいえ いいえ 操作中/現在ユーザーゲートは in_any_groups? を通じて行われます。
styleguide_allowed_groups スタイルガイドの可視性を指定されたグループのメンバーに制限します。 はい はい はい コントローラーは anonymous_users を明示的に処理します。また、変更前は everyone を通じて匿名ユーザーも許可していました。
「いいね！」 2
13

これらの調整を新しい PR に分離しました：

「いいね！」 2
14

@moin このPR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub はマージされ、現在 DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub でドキュメントを追加しています。DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub で discourse-copy-post を修正し、現在他の公式プラグインを調べて同じ対応が必要なものがないか確認しています（例えば、あなたが既に指摘した GitHub - discourse/discourse-unanswered-filter · GitHub など）。

あなたの Filter Favorites については、私が行った copy-post の例を見てもらえればわかりますが、基本的には default_favorite_filters_groups と custom_favorite_filters_allowed_groups の両方に resolve_group_membership: true を追加する必要があります。そうすると、ユーザーのグループ所属状況に応じて settings で settings.user_in_default_favorite_filters_groups および settings.user_in_custom_favorite_filters_allowed_groups としてブール値として利用可能になり、フロントエンドでユーザーのグループIDを手動でチェックする必要がなくなります。

default_favorite_filters_groups のデフォルト値をテーマコンポーネントで 4|5（ログインユーザーおよび匿名ユーザー）に変更し、0 (everyone)（近日中に廃止予定）を使用しないことをお勧めします。

everyoneグループを削除する際に、テーマ設定のDBマイグレーションを実行するようメモします。サイト設定についても同様のマイグレーションが必要です。これは、近日中に恒久的な変更に移行する際に実施されます（他の問題が発生するかどうか、および resolve_group_membership を追加する必要がある他のテーマ/コンポーネントの修正作業の進捗状況によって異なります）。

現時点では、サイト設定のような方法はありません… 現在追加する必要はないと思います。設定の説明で言及し、フロントエンドで currentUser でガードするだけで十分です。今後、より多くの需要があれば追加するかもしれません。

「いいね！」 2
15

オブジェクト設定の groups タイプでも機能しますか？

16

いいえ、必要でしょうか？このことは知りませんでした。権限に使用されているかどうかは分かりません。

17

例えば Discourse Group Sidebar Menus で、どのグループが各サイドバーセクションを表示できるかを管理者が設定できるようにするために使われていますし、Notification Banners では各バナーの表示可否を設定するために使われています。

おそらく adds コンポーネント でもそれを使うだろうと思っていましたが、実際はグループ名の文字列に依存しているようです。

私はグループタイプの設定を優先しようとしています。それはドロップダウンでグループを簡単に選択できるためで、グループID（名前に比べて変更されにくい）に依存しているからです。また、オブジェクト設定内のグループリストとリストタイプが同じように動作しないのは混乱を招くと思います。

私にとって、"everyone" は訪問者には機能しないため、結果として "trust_level_0" になります と書くのは、ドロップダウンが明示的に "anonymous_users" を提供している新しいバージョンとは異なります。たとえそれが機能しないと書いてあってもです。もし説明に記載するだけで十分なら、サイト設定でも同じことができたはずです。両方の設定タイプを使用する管理者にとって、一部の場所では機能しないグループが非表示になっているのに対し、他の場所では非表示になっていない理由を理解するのは難しいでしょう。これはコンポーネントの作成者が気にしなかったからではなく、その場所ではまだそれが不可能だからです。

「いいね！」 2