Change Details

After the BlockManager is introduced (T219441), move over the block-related methods on User, e.g. User::getBlock, User::blockedBy, etc. This will involve refactoring User::getBlockedStatus. User should determine whether to look for blocks against the IP address, but the method should return a block, rather than populating User properties. There will be a lot of callers to update too.

After the BlockManager is introduced (T219441), move over the block-related methods on User, e.g. `User::getBlock`, `User::blockedBy`, etc. This will involve removing `User::getBlockedStatus`, which currently determines whether to look for blocks against the request. The `BlockManager` should have two public methods: * One for checking if there are blocks relevant to the global request (against the global user, IP, referenced in a cookie, etc). Could return any type of `AbstractBlock`. * One for checking if there's a block saved against a particular target. Could return a `DatabaseBlock`. These essentially map to whether the caller is checking whether someone can actually do something in practice, or whether a caller wants to know if there's a block in the database against a particular target (e.g. to display a message on a User page, or when running a maintenance script like `BlockUsers`). See also the documentation for `BlockManager::getUserBlock`, which is currently internal, only called by `User::getBlockedStatus`: https://gerrit.wikimedia.org/g/mediawiki/core/+/9bf0a011626f2542b3abc07ee45dbd8437f70909/includes/block/BlockManager.php#95. There will be a lot of callers to update too.

After the BlockManager is introduced (T219441), move over the block-related methods on User, e.g. `User::getBlock`, `User::blockedBy`, etc. This will involve refactoring User::getBlockedStatusmoving `User::getBlockedStatus`, which currently determines whether to look for blocks against the request. The `BlockManager` should have two public methods: * One for checking if there are blocks relevant to the global request (against the global user, IP, referenced in a cookie, etc). Could return any type of `AbstractBlock`. * One for checking if there's a block saved against a particular target. Could return a `DatabaseBlock`. These essentially map to whether the caller is checking whether someone can actually do something in practice, or whether a caller wants to know if there's a block in the database against a particular target (e.g. to display a message on a User page, or when running a maintenance script like `BlockUsers`). User should determine whether to lookSee also the documentation for b`Blocks against the IP addressManager::getUserBlock`, but the method should return a blockwhich is currently internal, rather than populating User propertiesonly called by `User::getBlockedStatus`: https://gerrit.wikimedia.org/g/mediawiki/core/+/9bf0a011626f2542b3abc07ee45dbd8437f70909/includes/block/BlockManager.php#95. There will be a lot of callers to update too.