Change Details

**Problem** It is possible to have overlapping blocks. For instance you can have a block on your user as well as a hard block on an IP address (that also applies to your user). Likewise, you can have an IP Range block that could apply to your IP address and (possibly) your user (if it's a hard block). `User::getBlockedStatus()`picks a block to use and that is what gets used. This becomes a problem when overlapping blocks have different configuration. For instance, if a user is partially blocked from Saturn and IP address (hard block) is partially blocked from Mars, The user should be blocked from both Saturn and Mars. Likewise, if either of these blocks are sitewide blocks, the user should be sitewide blocked. Likewise, if a user is IP blocked and has an overlapping IP Range block, the user should have all of the restrictions of both blocks. **Solution** `User::getBlockedStatus()` should collect all of the blocks. (we could bail when we find the first sitewide block, but you can have overlapping sitewide blocks that have different restrictions... i.e. one could prevent account creation and another could prevent sending emails) If it finds more than one block, it should merge any restriction properties (email, user talk, page/namespace restrictions) from the blocks together. The merged block should not be able to be saved.

**Problem** It is possible to have overlapping blocks. For instance you can have a block on your user as well as a hard block on an IP address (that also applies to your user). Likewise, you can have an IP Range block that could apply to your IP address and (possibly) your user (if it's a hard block). `BlockManager::getUserBlock()` (formerly `User::getBlockedStatus()`) picks a block to use and that is what gets used. This becomes a problem when overlapping blocks have different configuration. For instance, if a user is partially blocked from Saturn and IP address (hard block) is partially blocked from Mars, The user should be blocked from both Saturn and Mars. Likewise, if either of these blocks are sitewide blocks, the user should be sitewide blocked. Likewise, if a user is IP blocked and has an overlapping IP Range block, the user should have all of the restrictions of both blocks. **Solution** `BlockManager::getUserBlock()` should collect all of the blocks. If it finds more than one block, it should merge any restriction properties (email, user talk, page/namespace restrictions) from the blocks together. The merged block should not be able to be saved.

**Problem** It is possible to have overlapping blocks. For instance you can have a block on your user as well as a hard block on an IP address (that also applies to your user). Likewise, you can have an IP Range block that could apply to your IP address and (possibly) your user (if it's a hard block). ``BlockManager::getUserBlock()` (formerly `User::getBlockedStatus()`) picks a block to use and that is what gets used. This becomes a problem when overlapping blocks have different configuration. For instance, if a user is partially blocked from Saturn and IP address (hard block) is partially blocked from Mars, The user should be blocked from both Saturn and Mars. Likewise, if either of these blocks are sitewide blocks, the user should be sitewide blocked. Likewise, if a user is IP blocked and has an overlapping IP Range block, the user should have all of the restrictions of both blocks. **Solution** `Us`BlockManager::getBlockedStatus()`UserBlock()` should collect all of the blocks. (we could bail when we find the first sitewide block, but you can have overlapping sitewide blocks that have different restrictions... i.e. one could prevent account creation and another could prevent sending emails) If it finds more than one block, it should merge any restriction properties (email, user talk, page/namespace restrictions) from the blocks together. The merged block should not be able to be saved.