Flow calls Title::userCan (https://github.com/wikimedia/mediawiki-extensions-Flow/blob/42e8d57fe5ff07d8c26b9d7add5e8749aecdd328/includes/WorkflowLoader.php#L249), which GlobalBlocking hooks into. Maybe something is bypassing that check?

Same deal with https://www.mediawiki.org/wiki/Special:Contributions/94.23.251.211 and https://www.mediawiki.org/wiki/Special:Contributions/123.125.19.44 , the latter of which is a single global block, so it is not limited to just global rangeblocks.

Also https://www.mediawiki.org/wiki/Special:Contributions/37.187.0.0/16

I don't know why the check is failing, but chances are that these are being submitted through the API, in case that makes a difference.

This also doesn't look good. https://www.mediawiki.org/wiki/Special:Block/185.8.237.178 is a tor node, so it might not just be limited to global blocks.

https://www.mediawiki.org/wiki/Special:Block/172.245.142.156 is both!

If I understand the report, it's saying that AbuseFilter is blocking it, whereas you expect it to be blocked by Flow.

Are there any edits that actually went all the way through when they were blocked at the edit-time?

Otherwise, this could just be a hook registration order issue.

Edit permissions should be being checked before it runs through the AbuseFilter. If the user can't edit the page, it shouldn't be wasting time running through the AbuseFilter/SpamBlacklist/etc.

(In reply to Kunal Mehta (Legoktm) from comment #7)

Edit permissions should be being checked before it runs through the
AbuseFilter. If the user can't edit the page, it shouldn't be wasting time
running through the AbuseFilter/SpamBlacklist/etc.

Yeah, I researched more closely after that, and they're different hooks anyway. AbuseFilter doesn't even use the getUserPermissionsErrorsExpensive/userCan hook

In core, EditPage->edit calls EditPage->getEditPermissionErrors

That calls Title->getUserPermissionsErrors with the default expensive true, which triggers hook checks

Later EditPage->edit calls EditPage->attemptSave(), which calls EditPage->internalAttemptSave().

That then calls EditPage->runPostMergeFilters which does the EditFilterMergedContent, etc checks.

Erik noted that in Flow, it's done in a different order. Specifically, WorkflowLoader calls Block->onSubmit early, which in turn calls Block->validate, which eventually checks the spam filters.

Then, only later does it check blocking and userCan.

Change 142170 had a related patch set uploaded by Mattflaschen:
Remove explicit isBlocked(), change permission ordering to match core

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

Change 142395 had a related patch set uploaded by EBernhardson:
Remove explicit isBlocked(), change permission ordering to match core

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

Change 142170 abandoned by EBernhardson:
Remove explicit isBlocked(), change permission ordering to match core

Reason:
@matt I'll go ahead and take over this patch

frontend-rewrite branch is closed, resubmitted against master as https://gerrit.wikimedia.org/r/142395

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

Change 142395 merged by jenkins-bot:
Remove explicit isBlocked(), change permission ordering to match core

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