# 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:** [13 mei 2026 om 01:18 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:** 5
**Page:** 3
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [8 september 2026 om 03:43 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/44 "2026-09-08T03:43:51Z")
> [@merefield](#):
>
> so some people were confused by everyone meaning just logged in users?
>
> who?!
>
> everyone is everyone surely - very clear.
No it wasn’t, and we have seen it come up time and again internally and externally, and all over the codebase.
> [@merefield](#):
>
> so now a Category that is fully public has to have a minimum of two groups now instead of one - logged in and anon? that’s silly and not an upgrade?
Haven’t gotten to categories yet, nothing has changed here.
> [@merefield](#):
>
> by changing just TL0 to “logged in users” you now break the consistency of each security level being a threshold. TL1 is _also_ a threshold and not really a “single group”. so does that mean we need a group called “logged in users who are at least trust level 1”?!
People were overwhelmingly using TL0 to mean “all logged in users” because we had no better way of representing this. The `logged_in_users` group at least is totally clear in what it entails, and there is absolutely nothing stopping you from still using TL0/TL1 etc. The only group being removed is `everyone`.
> [@merefield](#):
>
> change for change sake
Yes sure I am doing all this just for “change sake” 👍 Please consider for a moment your wording, we aren’t in the habit of doing totally unnecessary things for no reason here. This work has been ongoing for months now and it’s not changing direction.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [8 september 2026 om 07:03 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/45 "2026-09-08T07:03:22Z")
OK perhaps I’m misunderstanding this change?
If the proposal is to introduce:
- anon
- logged in
as automated groups
**that seems fine and they are self explanatory.**
(Indeed I quite like that! 👍)
If however the proposal is to _eventually_ remove:
- everyone
(you seem to be in the process of deprecation)
that doesn’t make sense to me as everyone is part of a set of automated groups that represent access thresholds which also include:
- trust\_level\_0
- trust\_level\_1
etc.
they _all_ represent thresholds of access, including everyone.
the everyone group is aka “trust\_level\_none”
**its a succinct way of spelling out public access.**
I appreciate you are not proposing to remove it for Category permissions for now (👍) but I’d personally like to see a commitment to keep this automated group as for me at least it makes sense.
and then why not allow it to be used elsewhere just as you would any automated trust level group?
otherwise everywhere you need to express something to have “public access” you are going to need to add **two** groups instead of one, which seems pointless complexity?
and why bother adding logic to “mask out” “everyone”?
perhaps another alternative approach is to reconsider the name “everyone” if a better name exists but keep its meaning and functionality and availability across the platform and then everyone (cough) is happy?
but given the name has survived for so long …
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [8 september 2026 om 07:59 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/46 "2026-09-08T07:59:38Z")
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.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [9 september 2026 om 18:32 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/47 "2026-09-09T18:32:53Z")
> [@martin](#):
>
> 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.
everyone is very explicit - this seems like unnecessary clunkiness to me - but appreciate the retained convenience.
> [@martin](#):
>
> 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.
imho that’s where the problem was/is and not with the original “everyone” Category concept.
“everyone” group and its use on the fundamental Category system has been around since … 2013?
>
If the settings system diverged and broke this contract that’s an issue with the work done on the settings system, no?
Imho it would have been nice to have an RFC for the community to contribute ideas to this before what seems to be heading straight into implementation. (Apologies if I missed something …)
That said I genuinely like the new automated groups.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [10 september 2026 om 00:06 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/48 "2026-09-10T00:06:53Z")
Yeah, I agree the inconsistency in site settings is part of the problem. But fixing that doesn’t necessarily mean keeping the existing `everyone` group in use for site settings.
I don’t think the 2013 argument tells us much beyond how long `everyone` has existed for category permissions. A ton of stuff has changed in Discourse since 2013; for example many site settings used to be trust level based, now they are group based. Nobody is disputing that it makes sense in that context, and category permissions are unchanged by this work (at least, for now). Its age doesn’t establish that it has a consistent meaning across the rest of Discourse, or that we should keep it indefinitely.
Even if we agree that every divergence from the original meaning was a mistake, we still have to deal with how those settings actually behave on existing sites. We can’t safely change their interpretation to include anonymous users just because that would better match the original category behaviour. As I explained above, keeping a universal group with a consistent meaning would still require auditing and migrating those uses. It’s an alternative design, but it doesn’t avoid the difficult part of this work.
On the RFC point, having a community RFC before making changes like this would be slow and prohibitive, though feedback is welcome, that’s what the upcoming change system is for. This topic has already led to several improvements from Moin’s examples, and I’ve acknowledged the theme/component cases I missed initially and fixed them too.
I’m happy to keep working through concrete issues with the change, but I’m still going ahead with the two explicit groups. Making public access convenient to select in the UI seems a reasonable way to address the extra clicking, but I don’t think it’s necessary right this second to implement.
Anyway I still have a ton of work tracked in [The road to stable, then permanent, for granular\_anonymous\_and\_logged\_in\_groups\_permissions](https://meta.discourse.org/t/the-road-to-stable-then-permanent-for-granular-anonymous-and-logged-in-groups-permissions/410178) for this, so this is a while off, as is any changes to do with the category system, which retains `everyone` for the time being. Categories are likely going to move to a system we are calling ACLs, which kanban already uses:
[Vorige pagina](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273.md?page=2)