Why would you want to modify this setting that nearly noone can use this feature in a useful way anymore? If no sysop can edit a filter to prevent and warn at editing, they become quite useless.

@MGChecker I think you read the task description backwards. I think the intention is to do the opposite of what you're saying.

Currently, AbuseFilterRestrictions contains array( 'block' => true, 'degroup' => true, 'blockautopromote' => true, 'rangeblock' => true ). (These actions aren't used at enwiki at all.) However, you talk about "blocking, preventing, and warning" in the task restriction.

Now I have to ask: What else could you possibly change except the thing I guessed? Probably there is some kind of misunderstanding here.

In T174624#3574555, @MGChecker wrote:

Currently, AbuseFilterRestrictions contains array( 'block' => true, 'degroup' => true, 'blockautopromote' => true, 'rangeblock' => true ). (These actions aren't used at enwiki at all.) However, you talk about "blocking, preventing, and warning" in the task restriction.

Now I have to ask: What else could you possibly change except the thing I guessed? Probably there is some kind of misunderstanding here.

// Disable some potentially dangerous actions
$wgAbuseFilterActions = [
	'block' => false,
	'rangeblock' => false,
	'degroup' => false,
];

By default on Wikimedia wikis the actions I listed above are disabled. My reading of this task is to change those defaults.

Is this task about wgAbuseFilterRestrictions¹ or about wgAbuseFilterActions²?

1. https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/8dc5c6427c7e2f0afdc443c7ddf731b63e3f30a2/AbuseFilter.php#L62-L68
2. https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/8dc5c6427c7e2f0afdc443c7ddf731b63e3f30a2/AbuseFilter.php#L34-L39

I believe (and please update this ticket if I'm incorrect!) that wgAbuseFilterRestrictions is the list of actions that are disabled if a filter hits too frequently.

@Legoktm: Well, I wasn't aware of this.

In T174624#3581060, @TBolliger wrote:

I believe (and please update this ticket if I'm incorrect!) that wgAbuseFilterRestrictions is the list of actions that are disabled if a filter hits too frequently.

Well, it's quite strange (considering it's about abusefilter not surprising), because AbuseFilter handles two things by this array. In my critic, I was focussed on the first, you on the latter:

1. abusefilter-modify isn't enough to edit filters with actions in $wgAbuseFilterRestrictions. You need abusefilter-modify-restricted for that. This permission isn't set for sysops on most projects
2. Only actions that are listed in $wgAbuseFilterRestrictions are turned off if the filter reaches certain threshold.

To be honest, I think this setting architecture isn't quite thought through and those settings should be splitted into two. The use cases when you want one or both of this don't really align at all.

In T174624#3586352, @MGChecker wrote:

@Legoktm: Well, I wasn't aware of this.

Well, it's quite strange (considering it's about abusefilter not surprising), because AbuseFilter handles two things by this array. In my critic, I was focussed on the first, you on the latter:

1. abusefilter-modify isn't enough to edit filters with actions in $wgAbuseFilterRestrictions. You need abusefilter-modify-restricted for that. This permission isn't set for sysops on most projects
2. Only actions that are listed in $wgAbuseFilterRestrictions are turned off if the filter reaches certain threshold.

To be honest, I think this setting architecture isn't quite thought through and those settings should be splitted into two. The use cases when you want one or both of this don't really align at all.

If I'm reading the code correctly, there are 2 more instances where $wgAbuseFilterRestrictions is used

1. To remove actions from global filters here
2. To remove disallow if there are more actions and quote from comments in the code, to prevent double warnings here

I agree with @Legoktm that these settings should be split. Maybe we should work on creating more descriptive globals and using them where it applies before working on this.

@dmaza — Can you please create that ticket?

@TBolliger T175221: Replace and split $wgAbuseFilterRestrictions responsibility with more verbose variable names.
Feedback is welcome. Specially about #4 listed on that task.