No it wasn’t, and we have seen it come up time and again internally and externally, and all over the codebase.
Haven’t gotten to categories yet, nothing has changed here.
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.
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.
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?
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:
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.
everyone is very explicit - this seems like unnecessary clunkiness to me - but appreciate the retained convenience.
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.
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.