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.
When b`User::getBlocks are enforcededStatus()` should user the current block selecting order, all blocks that apply to the user should be gathered (Userif it encounters a sitewide block, IP, Rangeit can bail with that block.
If it does **not** find a sitewide block, Cookiebut it does have one (or more) partial blocks, Proxyit should take the first block that is found, etc.) and should be merged together into a single block (perhaps of a new class?) with the most restrictive restriction of the set.and merge any restriction properties (email, user talk, For instance if one block is partial andpage/namespace restrictions) from the other is sitewide,blocks into it. then the sitewidThe block wshould take precedence.have a property that, If all blocks are partialwhen set, than all ofprevents the restrictions will be merged together.block from being saved (by throwing an error).