# Granular group-based permissions for anonymous and logged in users

**URL:** https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273
**Category:** Announcements
**Tags:** groups
**Created:** [May 13, 2026, 1:18am UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273 "2026-05-13T01:18:57Z")
**Posts on this page:** 1
**Showing post:** 46

<div class="post-metadata">

### Author: ![martin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/martin/32/491371_2.png) [@martin](https://meta.discourse.org/u/martin)
#### Post date: [September 8, 2026, 7:59am UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/46 "2026-09-08T07:59:38Z")

</div>

I think the distinction here is between keeping a convenient way to select “public access”, and keeping the existing `everyone` group. I agree that having to select two groups every time you want public access is more cumbersome, and we can improve that with UI.

For example, we could add a “Public” shortcut to the group picker which selects both `anonymous_users` and `logged_in_users` in one action. You would then see both groups selected, and could remove either one. That gives you the convenience you’re describing, while keeping the underlying permissions explicit. We would only offer that shortcut where both groups are allowed.

The problem with keeping the existing `everyone` group is that it hasn’t consistently meant “public access”. For category visibility it does, but for most group-based site settings it has effectively meant “all logged in users”. There are also themes and plugins interpreting it differently, as the discussion above has shown.

So we can’t just keep it and say it includes anonymous users everywhere without potentially granting access that wasn’t there before. Keeping its existing behaviour would preserve the inconsistency, and renaming it wouldn’t resolve that either.

A consistently defined universal group would be possible, but it would still require the migration and auditing we’re doing now. It would also need to be disallowed anywhere anonymous access isn’t supported, otherwise we’re back to “everyone” meaning “only logged in users” in those places. There are a ton of settings I’ve had to add `anonymous_users` as a `disallowed_groups` value where it wasn’t before, and before `everyone` was allowed on those settings. For example:

> [@martin](#):
>
> Further muddying the waters is the fact that this `@everyone` group can be used on site settings where it makes no sense for “all anon and logged in users” to have access to the feature, such as `pm_tags_allowed_for_groups`.

I’d prefer to provide that convenience in the UI, using the two explicit groups underneath, then we have consistency everywhere for admins and developers.

---

_[View the full topic](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273)._