Once https://gerrit.wikimedia.org/r/c/mediawiki/core/+/588104 is merged, we should have a backend class for blocking users.
Description
Description
Details
Details
Related Changes in Gerrit:
| 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
Comment Actions
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...
Comment Actions
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 :)
Comment Actions
Change 584128 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/AbuseFilter@master] Refactor AbuseFilterRunner::doAbuseFilterBlock to use SpecialBlock::processForm
Comment Actions
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?
Comment Actions
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
Comment Actions
Anti-Harassment-Team are looking into working on T221075: Introduce a BlockStore service as part of our work on blocking via Special:Investigate (T248528) if it helps.
Comment Actions
Change 633381 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Use new services in AbuseFilterRunner
Comment Actions
Change 633381 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Use new services in AbuseFilterRunner