Should this be visible for everyone?
AI-generated summary
The discussion is about the string “Admin.groups.manage.membership.automatic” not being replaced. Moin posted a screenshot showing the issue on an automatic group page, and HamMan2118 confirmed it appears on the Admins group page as well. Moin noted it affects all automatic group pages. The issue is that the tooltip is visible to everyone, but it should only be visible to those who can manage the group, such as admins, group owners, and moderators if the “moderators manage categories and groups” setting is enabled.
Moin suggested a fix, which involves adding a check to ensure the current user can manage the group before displaying the tooltip. zogstrip encouraged Moin to create a pull request, but Moin was unable to write tests. zogstrip offered to help, and Moin created a pull request.
However, zogstrip noted that the issue was more complex, and Moin pointed out that moderators can manage automatic groups if the “moderators manage categories and groups” setting is enabled. zogstrip asked for clarification on who can manage automatic groups, and martin explained that the site setting does allow moderators to manage automatic groups, but the client is sending mixed messages. martin created a follow-up pull request to change the check to canManageGroup and update the user model version of canManageGroup.
I think it appears at all automatic group pages. I chose “moderators” as the example for my screenshot, but staff, admins, and the trust level groups are also affected
note… added a priority tag here so we will have a look in the upcoming few weeks.
I think it’s quite easy to fix.
At the moment, the tooltip is visible for everyone, but it uses a string for the admin section:
I think the information is only relevant to those who can add group members. This can include admins, group owners, and, depending on the
moderators manage categories and groups setting, moderators. I believe that automatic groups cannot have owners, so anyone allowed to manage the automatic group should also be able to access the admin section string, and it could be hidden for everyone else.
+ {{#if this.canManageGroup}}
{{#if this.model.automatic}}
<DTooltip class="admin-group-automatic-tooltip">
<:trigger>
{{d-icon "gear"}}
{{i18n "admin.groups.manage.membership.automatic"}}
</:trigger>
<:content>
{{i18n "admin.groups.manage.membership.automatic_tooltip"}}
</:content>
</DTooltip>
{{/if}}
+ {{/if}}
Feel free to PR away @Moin ![]()
I am not able to write tests ![]()
No worries, I’ll take it then ![]()
Thanks, this will be fixed once this gets merged
It was missing a check to ensure the current user is an admin, since only admins can manage automatic groups.
Interesting. I thought moderators could too if moderators manage categories and groupsis enabled. The “manage” tab is visible for them.
That’s why I thought explaining why they cannot add members like they are able at other groups is helpful.
Automatic groups are handled differently I think, I saw some checks in the code that required admin, though that might be leftovers…
@hugh / @martin do either of you know who is able to manage automatic groups?
This topic was automatically closed after 16 hours. New replies are no longer allowed.
I think the site setting Moin mentioned does allow this, here is the relevant guardian check:
But in the client, we are sending mixed messages ![]()
Here is a followup PR to change to check canManageGroup, and also update the user model version of canManageGroup to be more sensible (the only place using that is from this group controller):




