|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|
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 :)
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?