martin
2026 年 5 月 13 日午前 1:18
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 としてマークしました。
既存のグループ名との競合は、既存のグループの名前を変更し、投稿内のグループメンションを更新することで自動的に処理されます。
これらの権限は変更されません。なぜなら、それらの「everyone」の概念はいくつかの点で異なり、基礎となる自動グループに依存していないためです。
「いいね！」 8
Jagster
2026 年 5 月 13 日午前 6:42
3
ちょっと待って… 何
martin
2026 年 5 月 13 日午前 6:45
4
いいえ、なぜなら：
これは現在、「全員」を選択できるグループリストタイプのサイト設定にのみ影響します。以下のように：
「いいね！」 1
Moin
2026 年 6 月 7 日午後 8:59
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 週間未満という期間は、潜在的に影響を受けるコミュニティ維持コンポーネントの数を考えると、かなり短いと感じます。unanswered filter コンポーネント も確認しましたが、そこにも変更は見つかりませんでした。重要な何かを見落としているような気がします。結局のところ、この変更はほぼ 1 週間前からデフォルトで有効になっています。そのため、調整が必要な場合、公式コンポーネントはすでに更新されているはずだと推測しています。
「いいね！」 1
HAWK
2026 年 6 月 7 日午後 10:28
6
3件の投稿が既存のトピックに統合されました：Foundationテーマの近代化
martin
2026 年 6 月 8 日午前 5:23
7
これらのコンポーネントを見ると、currentUser?.groups はそもそも信頼できません。なぜなら、これはユーザーに「表示される」グループのみを含み、権限に影響を与えるグループがここでシリアライズされていない可能性があるからです。
def groups
owned_group_ids = GroupUser.where(user_id: id, owner: true).pluck(:group_id).to_set
object
.visible_groups
.pluck(:id, :name, :has_messages)
.map do |id, name, has_messages|
group = { id: id, name: name, has_messages: has_messages }
group[:owner] = true if owned_group_ids.include?(id)
group
end
end
コアやプラグインでは、現在のユーザーシリアライザーで以下のような処理を行うことでこの問題を回避しています。
ただし、明らかにこれはテーマコンポーネントやテーマ、およびそれらの設定には利用できません。
うーん、確信が持てません。よく考えてみましょう。もし本当に everyone を意図していたのであれば、logged_in_users と anonymous_users の両方に変更する必要があります。これが OP で述べられた everyone の主な問題点でした。ある人はログインユーザーのみを意味すると解釈し、別の人はログインユーザー＋匿名ユーザーを意味すると解釈し、状況に大きく依存していたのです。
セキュリティの観点からより安全だったため、私は「ログインユーザーのみ」という解釈を選びました。
いいえ、テーマコンポーネントやテーマ、およびそれらの設定がどのように影響を受けるかについて考えが及んでいませんでした。私は主にサイト設定に焦点を当てていました。このような問題は特に発見するのが非常に難しいでしょう。なぜなら、AUTO_GROUPS 定数さえも使用していないからです。
とにかく、これらの問題に対するいくつかの解決策を考え出します。それらが解決されるまで、この変更を Stable ブランチに移行することはありません。
「いいね！」 2
martin
2026 年 6 月 26 日午前 1:46
9
クイックアップデートですが、この問題の対処法についてアイデアがあり、現在内部で検討中です。それほど時間はかからないはずです
「いいね！」 1
それって、その設定が有効になった時点で、現在「全員（everyone）」として公開されているすべてのカテゴリが、ログインが必要な「クローズド」カテゴリに自動的に切り替わるってことですか？
