Change 288571 had a related patch set uploaded (by Matěj Suchánek):
Add "abusefilter-exempt" right

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

Have you just added a possibility to bypass disallow and similar possibily destructive filter actions (block, blockautopromote, degroup) or a possibility to bypass tagging and warning too?

Probably the least horrible solution here is for AbuseFilter to provide a global skip flag that can be set by callers before they do an action that might trigger filters, which could then be set for system actions like LocalRenameJob, and triggered int the edit/upload special page and API via an extra boolean input field.

That's what I thought, too... Mostly because the front-end way of bypassing a filter shouldn't exist. That is, if you want someone not to hit a filter, you should code the filter to do that, mostly by excluding user groups. And assigning this right to global renamers would make them unaffected (or, respecting the points in the task description, less affected) by other filters for which they don't really need this flag. This is IMHO not ideal. Edge-cases like rename job should instead be handled back-end.

Global rename and other "internal" failures are definitely not a reason to add a bypass user right / checkbox. There might be other use cases; within filter logic you can only skip or affect (you can't for example say "prevent if user is not in group X, show a warning otherwise"; compare with titleblacklist etc. where functionaries can force the action but the check won't just get skipped without them being informed about the failure). But that's probably best discussed when someone has concrete use cases for it.

In T69936#4867327, @Tgr wrote:

Global rename and other "internal" failures are definitely not a reason to add a bypass user right / checkbox. There might be other use cases; within filter logic you can only skip or affect (you can't for example say "prevent if user is not in group X, show a warning otherwise"; compare with titleblacklist etc. where functionaries can force the action but the check won't just get skipped without them being informed about the failure). But that's probably best discussed when someone has concrete use cases for it.

Ditto. As for skipping, we already have warnings. In case a filter exists which targets both privileged and non-privileged people, and wants the former not to be affected by a disallowing action, the filter should probably be splitted.

So I filed T229252, which adds a hook to AF to let other extensions decide whether the current action should be filtered. And CentralAuth is doing that via a temporary user right, although that's not the possible way. I'm unsure whether the "proper way" in the task description is still useful to implement, or we can just close this bug as duplicate.

See also T36928: Create a user right that allows ignoring the spam blacklist - there may be objections to allowing people to bypass filters

In my opinion an abusefilter-bypass is useful though should normally be granted to no one permanently; my rationale is to prevent https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=WMFOffice&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter= from being happen.

@Daimona - can you clarify if you would be okay with adding abusefilter-bypass as a right that isn't given to anyone by default?

In T69936#5696073, @Bugreporter wrote:

In my opinion an abusefilter-bypass is useful though should normally be granted to no one permanently; my rationale is to prevent https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=WMFOffice&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter= from being happen.

To prevent those we'd have to assign the right permanently to the 'staff' group, wouldn't we? And then, what if a filter is actually meant to target *all* actions, included the ones by members of the "Staff" group? You simply can't. That's what I was saying: AF already has a precise way to exclude certain user groups from being targeted -- if you permanently exclude a user group, then you're effectively making this tool less precise.

@DannyS712 At the moment, I wouldn't (although I can change my mind, of course). This task asked for a "sane way" to bypass filters. Well, in my opinion, an "abusefilter-bypass" is not a sane way. Checking 'user_groups' is a sane way; having a hook for "unusual" backend stuff (e.g. global renames) is sane. For the WMFOffice case, a sane solution is being able to check for the 'staff' global group, which is currently impossible. I think we already have a feature request to include global user groups in the AF variables, but I cannot find it right now.

The right way to bypass filters would be that users with the abusefilter-bypass have a checkbox that they can use to suppress abusefilter effects. That's how it works for blacklists etc. Not sure if it's worth the effort and code complexity though, as Daimona says there are already ways to make the filter bypassable.

One thing that might help is to provide pseudo-user groups such as crosswiki autoconfirmed (has more than X total edits, not necessarily the current wiki) or privileged anywhere, to make it easier to avoid gotchas like not adding stewards to the skip list. (cf. T208477: Move "privileged account' concept into MediaWiki core)

In T69936#5698208, @Tgr wrote:

The right way to bypass filters would be that users with the abusefilter-bypass have a checkbox that they can use to suppress abusefilter effects. That's how it works for blacklists etc.

Saner, yes. Whether this is completely sane, I wouldn't be sure. You'd still be offering a way to bypass a tool that's already supposed to check whether you're allowed to bypass it or not.

Not sure if it's worth the effort and code complexity though, as Daimona says there are already ways to make the filter bypassable.

But yes, either way I think it's not worth doing anything further (unless we find a good reason to do so).

One thing that might help is to provide pseudo-user groups such as crosswiki autoconfirmed (has more than X total edits, not necessarily the current wiki) or privileged anywhere, to make it easier to avoid gotchas like not adding stewards to the skip list. (cf. T208477: Move "privileged account' concept into MediaWiki core)

Yes, this would be great. BTW, I was wrong in my previous comment: we already have a variable for global user groups (global_user_groups) - it's just "invisible" because it's only computed if a filter requires it.

hmm we even have a dedicated extension that add a right bypassing all abusefilters: https://www.mediawiki.org/wiki/Extension:AbuseFilterBypass

Doesn't this just boil down to making UltimateAuthority bypass abusefilter?

In T69936#10374326, @MGChecker wrote:

Doesn't this just boil down to making UltimateAuthority bypass abusefilter?

Em, such as this one (https://gerrit.wikimedia.org/r/1049531), but this is just an extension. And we need to fix core and other extensions that calls abusefilter.

Also, my second point still holds.

Yes, but I mean within the abusefilter extension, not within the callers.