Background

For T406544: Create a way to technically enforce policies for restricted groups, we will need a service that can validate whether a user can be added to a restricted group, depending on the characteristics of the user to be added to the group and the user performing the group change.

Details

Status quo

UserGroupAssignmentService::computeChangeableGroups works out which groups can be added and removed, and which are restricted, given a target user and a performer.

It runs a hook SpecialUserRightsChangeableGroups that allows extensions to define restricted groups; however this requires the extension to do work that could be made more generic. E.g. CheckUser's handler re-implements condition checking for group membership, account age and minimum edits, which could be handled more generically by UserRequirementsConditionChecker.

Planned improvement

T406544: Create a way to technically enforce policies for restricted groups proposes a configuration that defines:

• what groups are restricted
• what conditions must be met by the target and by the performer (same format as $wgAutopromote)
• whether some performers can ignore these restrictions

Extensions can add extra conditions, via AutopromoteConditionHook (which should probably be renamed to something more generic).

A new service (e.g. RestrictedGroupValidator) would handle this configuration, and report back to UserGroupAssignmentService::computeChangeableGroups whether the group can be added (or removed or have the expiry updated).

The service would make use of UserRequirementsConditionChecker to check the conditions.

Outline for new service

This is a rough sketch of what the service would do.

When checking if changeable groups for a given target, performer and group:

• doesTargetMeetRequirements
  • checks conditions using UserRequirementsConditionChecker
• doesPerformerMeetRequirements
  • checks conditions using UserRequirementsConditionChecker
• canPerformerAddTargetToGroup
  • if group not restricted, return false
  • if group restrictions can be ignored and performer has ignore-restricted-groups right, return true
  • if performer doesn't meet requirements, return false
  • return target meets requirements
• canPerformerRemoveTargetFromGroup
  • could return true, since it is beyond the scope of T406544
• canPerformerUpdateGroupExpiryForTarget (see T407886#11334416)
  • could return canAddGroup (doing something more complicated like allowing extend but not shorten may be beyond the scope of T406544)

When checking if a user can actually use a group (will be spun out to a new task once we understand requirements - see T407886#11334416):

• canUseGroup
  • if group not restricted, return true
  • if group restriction can be ignored, return true since the user may never have met requirements
  • return doesUserMeetRequirements

Acceptance criteria

• The new service exists, works and is tested
• The new service is ready to be used for the temporary-account-viewer group