Page MenuHomePhabricator

Add option to prevent users from adding themselves to or removing themselves from a user group
Open, LowPublic

Description

Problem statement

We want it to be possible to allow a user to remove/add users to a group but without allowing them to remove/add themselves to those groups.

Background

The $wgAddGroups and $wgRemoveGroups configuration variables control which user groups can be added or removed by users in a certain group. This is used to allow splitting up the big responsibility of "bureaucrat". For example, at WMF a sysop user can usually not grant any group memberships, but through this mechanism granting of ipblock-exempt is enabled. It also goes in the other direction in that bureaucrat users are not able to grant checkuser or steward permissions.

The $wgGroupsAddToSelf and wgGroupsRemoveFromSelf configuration variables allow granting users the ability to only toggle a user right that they are generally already entrusted with, but for technical reasons don't want permanently enabled. At WMF this is used as a hack for being able to use the "bot flag" for several edits in a row to avoid spamming RecentChanges (the "flood" user group).

Author: hersfoldwiki

Description:
$wgGroupsRemoveFromSelf allows the site manager to specify what groups a user can remove from themselves, even if they would otherwise not be able to do so. I am requesting the inverse of this; a variable that allows the site manager to specify what groups they cannot remove from themselves, even if they can remove it from others.

The main utility of this feature would be that you can ensure that there is always at least one member of the group. Imagine a setup like this:

$wgGroupPermissions['bureaucrat']['userrights'] = false;
$wgAddGroups['bureaucrat'] = array( 'sysop', 'bot', 'bureaucrat' );
$wgRemoveGroups['bureaucrat'] = array( 'sysop', 'bot', 'bureaucrat' );
$wgAddGroups['serveradmin'] = array( 'serveradmin' );
$wgRemoveGroups['serveradmin'] = array( 'serveradmin' );

Here, only serveradmins can promote or demote other serveradmins (obviously for this to work, these options would have to be added piece-meal or database wonkery gets involved, but ignore that for now, it's irrelevant). Thus, if the only member of the group accidentally removes themself from the group, they cannot re-add themselves to it, nor can any one else add themselves to the group.

A new $wgGroupsCannotRemoveFromSelf variable could be set up, with the same syntax, to specify that "serveradmins cannot remove themselves from the serveradmin group", which should help to ensure that accidential clicks are not entirely disastrous.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:02 AM
bzimport set Reference to bz42072.
bzimport added a subscriber: Unknown Object (MLST).

Do you really still run 1.18.1? Any chance to upgrade to something supported?

hersfoldwiki wrote:

Yes, the wiki I manage at my workplace still uses 1.18.1. I think there may have been some reason why we didn't upgrade to anything more recent, but I can't remember now just what that would have been. Regardless, it's likely to stay that way for a fair bit, as I'm currently assigned to another project and I'm not technically being paid to do any of the wiki stuff right now.

DannyS712 subscribed.

Per comment at T230805#5424859, this should be expanded to include adding flags to others but not self. Rather than setting what a user can remove, and then removing from that what they cannot remove from themselves, I think it'll be easier if we have, like wgGroupsRemoveFromSelf and wgRemoveGroups, wgGroupsRemoveFromOthers than only allows removing the right from others.

Change 531319 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Add wgGroupsRemoveFromOthers and wgGroupsAddToOthers user group configuration options.

https://gerrit.wikimedia.org/r/531319

Thanks @DannyS712, if you can push the request through Platform Engineering that's more consistent for us when triaging. We're hoping to catch up on reviews this sprint, apologies for the delays we'll try to clear out the queue as quickly as possible.

Thanks @DannyS712, if you can push the request through Platform Engineering that's more consistent for us when triaging. We're hoping to catch up on reviews this sprint, apologies for the delays we'll try to clear out the queue as quickly as possible.

I'm not sure what you mean - I tagged Platform Engineering in T44072#5457812 - is there a step I missed?

Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l-list.

Technical reasons aside - may I ask - Why should bureaucrats not be able to grant themselves the rights they are able to grant others?

It's not explained on this task what problems it is intended to solve, which I think is important to document so our future selves know how to develop it further if some of these systems need to be replaced one day.

@Krinkle for example, on enwiki, an RfC (https://en.wikipedia.org/w/index.php?oldid=857728137#Sysop_as_requirement) held that 'crats shouldn't give themselves interface administrator rights. Setting wgGroupsAddToOthers['bureaucrat']['interface-admin'] = true; rather than using wgAddGroups would allow enforcing this. It would also ensure, per the use case in the summary, that there is always at least one 'crat left if they could only remove it from other users.

Why is a technical enforcement requirement for a social policy? Technical enforcement is imho only useful if it helps maintain validity of the software state or can prevent misuse. Neither appears to be the case here. Also, I could not find in the linked discussion that EnWiki is seeking for a technical enforcement. Was this discussed?

A bureaucrat could just as easily grant the right to a sockpuppet they control, or person they know. If they violate this trust, they cannot be trusted with crat rights. This is unlike other capabilities as these two are in fact the same concept being applied.

The case of losing access is why we have multiple layers of this, including stewards, as well as sysadmins. Both of which are able to grant new crat rights if needed. Has this become an actual problem in practice?

Why is a technical enforcement requirement for a social policy? Technical enforcement is imho only useful if it helps maintain validity of the software state or can prevent misuse. Neither appears to be the case here. Also, I could not find in the linked discussion that EnWiki is seeking for a technical enforcement. Was this discussed?

A bureaucrat could just as easily grant the right to a sockpuppet they control, or person they know. If they violate this trust, they cannot be trusted with crat rights. This is unlike other capabilities as these two are in fact the same concept being applied.

The case of losing access is why we have multiple layers of this, including stewards, as well as sysadmins. Both of which are able to grant new crat rights if needed. Has this become an actual problem in practice?

These multiple layers work for the wmf cluster, but for individual independent wikis only sysadmins would be able to help, and this would ensure that there isn't a need for adding user groups from the command line in case someone makes a mistake. I only added the enwiki policy as an example of where it could be useful here; the original use case presented in the task description is the primary reason for the change.

Okay, I understand. I assumed you wanted this for Wikipedia because the original request is dates to 2012 (imported from Bugzilla) and might not be relevant anymore, given no feedback since.

In any event, I'll let CPT handle the product decision on whether this should be a core feature and how we want to present it to sysadmins.

DannyS712 renamed this task from Add option to prevent users from removing themselves from a user group to Add option to prevent users from adding themselves to or removing themselves from a user group.Dec 4 2019, 2:37 AM
Aklapper subscribed.

Removing task assignee due to inactivity, as this open task has been assigned for more than two years. See the email sent to the task assignee on February 06th 2022 (and T295729).

Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.

If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".

Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.