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.
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.
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.