Change #1203460 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@master] WIP UserGroupAssignmentService: Check for restricted groups

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

What to do about the message shown when the conditions are not met?

Status quo

Target doesn't meet criteria
Target doesn't meet criteria but performer is exempted
Target meets criteria (no indication that group is restricted)

Questions for the new system

We can consider these more fully in a separate task

• Should we allow showing different messages depending on whether the performer/target meet requirements?
• Should we actually show which conditions weren't met?
• Should we keep it simple and allow defining just one message per group, which could e.g. link to policies?
• Should we show these messages even if all conditions are met - would this be useful information or noise?

For this task

When to show the message: Let's keep the status quo for now - only showing it when the requirements are not met - but consider whether we should always show it, while we're considering everything else about the messaging.

Whether to allow configuring the message: I'm tempted not to add messages to the RestrictedGroups configuration right now since it's not clear what we need (one message, several messages?). Instead we could check for the existence of a message defined for a particular group, and show a default message otherwise.

Change #1203460 merged by jenkins-bot:

[mediawiki/core@master] UserGroupAssignmentService: Check for restricted groups

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

Change #1212197 had a related patch set uploaded (by Reedy; author: Tchanders):

[mediawiki/core@REL1_45] UserGroupAssignmentService: Check for restricted groups

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

Change #1212197 abandoned by Reedy:

[mediawiki/core@REL1_45] UserGroupAssignmentService: Check for restricted groups

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

I tested different groups with different combinations of memberConditions, updaterConditions and canBeIgnored being true or false.

If the performer has the ignore-restricted-groups rights, they can assign users to groups with canBeIgnored = true regardless of whether memberConditions or updaterConditions has been met. They cannot assign groups that have canBeIgnored = false unless both memberConditions and updaterConditions have been met.

If the performer does not have the ignore-restricted-groups rights, they can only assign groups when both memberConditions and updaterConditions have been met.

If a user already is in a group, I can remove them from the group regardless of whether memberConditions or updaterConditions have been met, whether canBeIgnored is true or false and whether I have the ignore-restricted-groups right. In this case, there is an * next to the groups I would not normally be allowed to add users to.

I tested this on Special:UserRights and via the action=userrights API.

I briefly tested the UI in different skins and languages. I found T411260 (which may be expected behaviour) and T411261.