Page MenuHomePhabricator

Rename or delete 'suppress' user group on Wikimedia wikis
Closed, ResolvedPublic

Description

I suppose some bug on this issue must exist already, but I could not find any.
Currently, we have by default two user groups using identical i18n names ('oversight' and 'suppress'). Since 'oversight', just like 'sysop', is to be deprecated in distant future in favour of 'suppress'/'admin', I think the internal group name for the group containing only the 'flow-suppress' user right is inappropriate. Furthermore, I am not quite sure why flow-suppress needs an own isolated user group at all. Does a use case even exist anywhere?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

This appears to be regarding: (for example) https://www.mediawiki.org/wiki/Special:ListGroupRights (please always add examples/links!)
which currently lists 2 user-groups ("Oversighters" and "Suppressors") both of whom have the user-right flow-suppress. However, the Suppressors user-group has no users (on mediawikiwiki or metawiki), and I don't recall any discussions about splitting it, so probably it's just a variable naming error somewhere. (Naming things is hard! Sticking with a single name, is apparently even harder! That is usually what causes problems like this one!)

Since 'oversight', just like 'sysop', is to be deprecated in distant future in favour of 'suppress'/'admin',

Is one or both of those changes being discussed somewhere, again? Links appreciated! Thanks.

Change 324012 had a related patch set uploaded (by Catrope):
Stop assigning rights to the nonexistent 'suppress' group

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

+1

The suppress doesn't exist by default indeed, but core does pretend that it is (or once was, or intended to be) a "common" group to want to have on wikis, given it has the following commented-out code in DefaultSettings.php:

# $wgGroupPermissions['sysop']['deletelogentry'] = true;
# $wgGroupPermissions['sysop']['deleterevision'] = true;
// To hide usernames from users and Sysops
# $wgGroupPermissions['suppress']['hideuser'] = true;
// To hide revisions/log items from users and Sysops
# $wgGroupPermissions['suppress']['suppressrevision'] = true;
// To view revisions/log items hidden from users and Sysops
# $wgGroupPermissions['suppress']['viewsuppressed'] = true;
// For private suppression log access
# $wgGroupPermissions['suppress']['suppressionlog'] = true;

/**
 * The developer group is deprecated, but can be activated if need be
 * to use the 'lockdb' and 'unlockdb' special pages. Those require
 * that a lock file be defined and creatable/removable by the web
 * server.
 */
# $wgGroupPermissions['developer']['siteadmin'] = true;

Change 324012 merged by jenkins-bot:
Stop assigning rights to the nonexistent 'suppress' group

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

It turns out this group existed only because Flow assigned rights to it. Thanks @Krinkle for merging this so quickly.

It turns out this group existed only because Flow assigned rights to it. Thanks @Krinkle for merging this so quickly.

It existed because:

  1. group-suppress exists in core.
  2. Krenair said at https://gerrit.wikimedia.org/r/#/c/222069/ that the group 'oversight' was being phased out (and referenced T109327: Don't use deprecated message group-oversight-member). Apparently, the idea of renaming the group to 'suppress' (T112147) was later dropped/rescheduled.
Catrope claimed this task.