Background

Some groups have requirements, e.g. that the group member must have 2FA, or a minimum edit count / account age, or have signed an agreement.

At the moment, some of these requirements are enforced by MediaWiki, and others are checked manually. Of those that are enforced, the enforcement is done ad hoc and in different ways. To enforce a new requirement for a new group, a software change must be made.

This task is for creating a general way to configure enforcement, so it is easier to understand which groups have which requirements, and to add a new group requirement.

This task is not for technically enforcing all group requirements. Instead, those that are currently enforced will be migrated to the new system, and whether to enforce others will be discussed and decided on a case-by-case basis.

Feature requirements

The new system should allow:

• Defining restricted groups, where members must meet requirements
• Restricting adding to a restricted group depending on attributes of the user to be added
• Restricting adding, removing and updating expiry of a restricted group depending on attributes of the performing user
• Exceptions, where a restricted group may be added without the user meeting requirements, by a particularly trusted user
• Checking whether requirements are still met when the user tries to use rights conferred by a restricted group (note that this won't be possible for a group where users can be added without meeting requirements)
• Enacting consequences if a restricted group's member no longer meets requirements

The same system should be used by local and global groups.

We will also consider:

• How to enforce requirements for particular rights (as opposed to groups)

Technical outline

A new configuration will define which groups are restricted, and how:

// Restricted groups config
// - conditions are the same as $wgAutopromote
// - to add, target must meet memberConditions AND performer must meet updaterConditions
// - to remove or update expiry, performer must meet updaterConditions
// - if canBeIgnored, user with the 'ignore-restricted-groups' right can update the group without checking the conditions
// - if canBeIgnored, member's conditions are not checked again
// - if !canBeIgnored, check the conditions every time membership is checked
$wgRestrictedGroups = [
	'groupName' => [
		'memberConditions' => $condsArrayForMember,
		'updaterConditions' => $condsArrayForPerformer,
		'canBeIgnored' => $canBeIgnored,
	],
	...
];

// Restricted rights config
// - conditions are the same as $wgAutopromote
$wgRestrictedRights = [
	'groupName' => $condsArray,
	...
];

A new right, 'ignore-restricted-groups', will allow some users to ignore requirements, for some groups.

New services:

• A service for validating restricted groups which will have public methods like canAddGroup( $group, $target, $performer ) and canUseGroup( $group, $user )
• A service for checking that users meet conditions, refactored from UserGroupManager::recursiveCheckCondition and ::checkCondition, which is called by the group validator service: T406547
• Potentially a rights validator service with canUseRight( $right, $user )