Once https://gerrit.wikimedia.org/r/c/mediawiki/core/+/588104 is merged, we should have a backend class for blocking users.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Daimona | T248743 Call BlockUser in AbuseFilterRunner.php | |||
Resolved | Urbanecm | T189073 Refactor logic for creating and logging a block out of SpecialBlock so it can be easily reused elsewhere | |||
Resolved | Urbanecm | T248640 Make blockUsers.php script capable of unblocking | |||
Resolved | Urbanecm | T251861 Move SpecialBlock::checkUnblockSelf to a block permissions service | |||
Resolved | Urbanecm | T263326 Deprecate SpecialBlock::checkUnblockSelf | |||
Resolved | Urbanecm | T263327 Deprecate SpecialBlock::canBlockEmail and replace its usages | |||
Resolved | Urbanecm | T263334 Do not call SpecialBlock::canBlockEmail from CheckUser | |||
Resolved | Tchanders | T264307 Deprecate SpecialBlock::processForm |
Event Timeline
Personally, I just wasn't aware of that method. I can't tell whether it could break anything though.
Of note, before trying, perhaps the method should be moved elsewhere, as calling ::processForm from a non-form context looks weird...
Ditto. I somehow missed it when doing T246368: Create maintenance script to block a list of users, when the API clearly uses it (and I'm sure I looked at the APIs code)
It shouldn't be too difficult to confirm all the parameters get swapped over etc
I don't disagree that it probably should live somewhere else, but that's probably more in scope for something like T221075: Introduce a BlockStore service (or another block refactoring type task), rather than here :)
Change 584128 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/AbuseFilter@master] Refactor AbuseFilterRunner::doAbuseFilterBlock to use SpecialBlock::processForm
Sure, it doesn't belong here. However, I was wondering whether we should wait for that service to be created, before migrating the caller. I've skimmed through the patch above, and the first thing I noticed is that SpecialBlock::processForm has an annoying depdnency on a whole RequestContext object. As I wrote on gerrit, that's a pattern we tend to avoid in new code, because it's very hard to maintain (and it introduces a lot of coupling).
So, perhaps we should really wait for that service to be created before moving on?
Change 584128 abandoned by Urbanecm:
Refactor AbuseFilterRunner::doAbuseFilterBlock to use SpecialBlock::processForm
Reason:
wait for https://gerrit.wikimedia.org/r/c/mediawiki/core/ /588104 to be reviewed&merged
Anti-Harassment are looking into working on T221075: Introduce a BlockStore service as part of our work on blocking via Special:Investigate (T248528) if it helps.
Change 633381 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Use new services in AbuseFilterRunner
Change 633381 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Use new services in AbuseFilterRunner