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

コードベース内には、歴史的に混乱を招いてきた @everyone という疑似グループがあり、以下に使用できます:

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

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

さらに混乱を招いているのは、この @everyone グループが、pm_tags_allowed_for_groups のように、「すべての匿名およびログイン済みユーザー」が機能にアクセスすることが意味をなさないサイト設定で使用できてしまう点です。

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

解決策

2 つの独立した自動疑似グループを導入します:

  • anonymous (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 のように、意味をなさないいくつかのサイト設定に対して anonymousdisallowed_group としてマークしました。

タグおよびカテゴリ権限についてはどうなるか?

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

「いいね!」 3

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

いいえ、なぜなら:

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

「いいね!」 1