(One person’s feature request is another person’s bug report… )
The “Groups” index page (e.g., /groups or /g), should respect the visibility settings of the automatic groups, and display them accordingly. It does this for the Moderators group, but not the others. This is due to a hard-coded exception in GroupsController.index(), which causes the other automatic groups to never appear on the index page when viewed by non-staff users, no matter what the visibility settings are.
This exceptional behavior is problematic in at least two ways:
If an admin wants to index automatic groups for non-staff users, this prevents them from doing that.
The disconnect between the visibility setting and the actual visibility is dangerously confusing. In particular, it makes it seem like the setting is ignored/irrelevant for automatic groups (e.g., “Gee, I guess automatic groups are always staff-only, no matter what I set this to…”), even though the setting does continue to control access to specific group pages (e.g., /g/trust_level_0) and their member-lists.
A comment in the relevant code indicates that this exceptional behavior is intended to “hide automatic groups from all non stuff to de-clutter page” — but there is no need for this mechanism to accomplish that. An admin who wants to de-clutter the index page could simply set the visibility of automatic groups as they see fit, just as they would with any other group.
I suggest simply removing the 6 lines of code from app/controllers/groups_controller.rb that implements this behavior.
If it is considered that important to default to a “de-cluttered” index for new installations of Discourse, then a better mechanism would be to simply default to staff-only visibility settings for the automatic groups when they are first created by the system. to set the default filter on the index page to “non-automatic” for non-staff users.
(The visibility setting is an access control — the default value should be whatever constitutes a sane default level of access, regardless of what the index page looks like.)
FYI, this topic is a follow-up to the discussion in:
As a regular user I prefer the decluttered view, the trust level groups don’t seem relevant to me. But I also agree that the way things work now seems odd. Especially given this:
If the trust level group pages are useful, there should be a way to access them via the UI, without having to know the URL.
That makes sense to me. Some care might need to be taken to make sure that limiting the visibility of a trust level group doesn’t break anything. Currently, it’s not possible to create public events if the TL0 group isn’t visible to the user who creates the event. I’m not sure if there are other cases similar to that.
having “Automatic Groups” available in the filter dropdown for non-admins?
making the default filter (both for admins and regular users) exclude the automatic groups
making sure that /g/trust_level_0?asc=true uses the same authorization logic as /g?type=automatic (currently the former works while the latter says “There are no visible groups.”
Additional request: if /g is accessed via /admin then suddenly the admin menu bars disappear. I find this annoying. How about adding those menu bars to that page if /g is accessed by an admin?
Yes, “duh” as one says… I have edited my original proposal to reflect this. “Visibility” is an access control, and should be treated as such (e.g., the UI should transparently reflect the state of the control, instead of the control being twisted to tune the look of the UI).
Indeed! I hadn’t noticed that “automatic” is not available in the filter dropdown for non-staff. (It is elided by the same 6-line block of code that hides the automatic groups — so removing that code would fix that too.)
The backend code does already define a “non_automatic” filter, though it seems to never be offered to anyone (staff or not) in the filter dropdown.
When you say “index automatic groups for non-staff users”, do you mean allow non-staff users to be able to access the automatic groups filter and see them?
This is a legit concern. We are trying to make the admin experience more straightforward and consistent, and this seems to be an area that can trip people up. I have not heard any other complaints about this particular case but I can see the value in fixing it so the behavior is consistent.
These two items seem to make sense. However, before we do this are there any unintended consequences of changing the visibility settings for automatic groups?
This looks good as a todo list. Thanks for framing it this way.
In that quoted text, I specifically mean “show automatic groups on the /g index page when viewed by non-staff users”. Regardless of the filter setting, the automatic groups (except for “Moderators”) are currently not allowed to be listed on the /g index page for non-staff users.
In a later post (the one preceding this one), I additionally advocate for providing the “Automatic Groups” option in the filter dropdown for all users, not just stafff users. I don’t think there is a good reason to hide it from non-staff users. (Note that no matter what is presented in the dropdown menu, the filter is still available to any user who can type the correct keyword into the URL bar.)
Please note that I edited my suggestion for default de-cluttering prior to your post; you have quoted the original version. The revised/current text from my first post is (with the strikeouts removed for brevity):
Currently, the user list looks like the below on a new site.
To summarize in my own words, the request is to change the group directory at /g as follows:
also display Automatic Groups filter to members
display all automatic groups to members when filter is selected
exclude Automatic Groups from the default view at /g
My feeling is that (3) should be for everyone, not just for members. One goal we have is to give admins and moderators as close to the same experience members have, to reduce confusion.
By making this change, we are just making explicit in the UI the existence of automatic groups which members have access to but currently need to know the URL.
I would rephrase, in terms of the changes to be made, and reprioritize a bit:
A. stop removing automatic groups from the index for non-staff users
B. stop removing the “Automatic Groups” filter from the dropdown menu for non-staff users
C. offer the “Non-Automatic Groups” filter in the dropdown menu, to all users
D. engage the “Non-Automatic Groups” filter by default at /g
My phrasing of C and D, as compared to 3, is intentional: I think the UI should be very transparent about what filtering is in effect. If no filter is selected, then the UI should present an unfiltered view, i.e., show every group that is visible/accessible to the user.
One could interpret 3 as “when no filter is selected, then quietly use the non_automatic filter”, but I think that would still be confusing. If no filter is selected, then there should simply be no filter applied. Conversely, if a filter is being applied, it should be named and made apparent to the user.
Diving deeper into the weeds here: part of the filter selection problem arises from the way the “Filter by group type” hint has been squeezed into the label for the no-filter-selected menu item. I think it would ultimately be more clear if the no-filter-selected item were labeled “All Groups”. Then, add an additional “Non-Automatic Groups” item, and you are free to make either item the default. This way, (a) it is clear when the user is receiving a filtered view, and (b) it is clear how to switch to an unfiltered view.
If it were up to me, I would label the filter menu-items as:
All Groups
Groups I belong to(because My Groups is ambiguous.)
Groups I own
Public Groups
Private Groups(because Closed sounds like “shut down” or “no longer in use”.)
Automatic Groups
Non-Automatic Groups
And, I would change the hint string in the text-box, from “All Groups” to “filter by group name”.
And… I would swap the order of the pulldown menu and the text-box!
Thanks for helping think this through. I don’t think we’re likely to make bigger changes to the groups list UX for the moment, but I do like the idea of at least making the group list function the same for everyone.
These all good suggestions, except I find"Automatic" and “Non-Automatic” to be clunky, techie sounding names and not so meaningful. Since automatic groups are all about privileges people have attained or been granted, maybe we can come up with a label that reflects that?
Just came here with the same thought, that it would be better to have the default view on what is nowadays called “Public + Closed Groups”, thus introducing such an option. And removing the ambiguities around “My Groups”, which could be understood as what “Group I own” actually means, and “Closed Groups”, which could sound like they are no longer active, seems reasonable, too.
These sound a lot like:
System Groups
User Groups, “Public & Private Groups”, or just Groups
Maybe the order of groups offered in this filter item could be configured, with the first item always being the default view, so we can choose that. Else finding a suitable default order which works for everyone, plus allowing one of these view to be defaulted, would be another question.
Also, being able to give human-readable name aliases to “Automatic/System Groups”, for example some languages prefer capital letters in the beginning, as with the Full Name field in regular groups and providing them with optional, sane default description texts could render those appear less “technical”, if a site administrator doesn’t choose to explain them in their description via their Manage menu.
Maybe there could also be some kind of visual distinction between “Automatic” and “Non-Automatic” groups, like an icon, or their boxes being shaded in light gray, or something.
“Automatic” sounds like it’s referring to how an implementation detail - users are added to the groups automatically. I don’t think that makes much sense from a regular users point of view. It’s also not strictly accurate. Users aren’t automatically added to the staff groups. Probably the most accurate name for the automatic groups would be “pre-seeded groups”, but that’s a terrible name.
“System” groups sounds ok, but what about dividing the automatic groups into “Trust Levels” and “Staff”? The groups type filter would be something like:
My Groups
Groups I own
Public Groups
Closed Groups
Trust Levels
Staff
If needed, there could be something like a trust level groups public site setting that would determine whether or not the trust level groups were visible on the groups page.
Separating out site staff is a good idea. People might actually appreciate discovering a list of moderators and admins here. Otherwise they have to know to go to /about.
Chiming in again… please count me in the set of discourse users/administrators who does not really need a “show everything except the system/automatic groups” filter. The presence of those groups just doesn’t seem that distracting.
Either way, my priority is to make a true “All Groups” un-filtered filter available, and my own preference is to keep-it-simple and have that be the default for the /groups page.
)
