The main reasons for adding this service layer are:
* It allows error messages to be more consistent, by defining
a set of reportable information that can describe any block
type and is consistently formatted.
* It decouples formatting from the block classes, removing
their dependency on language, for the most part.
The service provides one public method, getMessage, which
returns a Message object whose key and parameters are
determined by the type of block. This should be used instead
of the deprecated AbstractBlock::getPermissionsError and
AbstractBlock::getBlockErrorParams.
Calls to AbstractBlock::getPermissionsError are replaced in
this patch.
Bug: T227174
Change-Id: I8caae7e30a46ef7120a86a4e5e6f30ae00855063
CompositeBlock::appliesToRight checks $block->appliesToRight()
for each of the original blocks from which it is made.
AbstractBlock::appliesToRight returns:
* true if the block applies to the right
* false if the block does not apply to the right
* null if unsure
Before this, CompositeBlock::appliesToRight can only return true
or false. After this, it returns:
* false if false for all of the original blocks
* true if true for one or more original blocks
* null otherwise
Bug: T229417
Bug: T231145
Change-Id: Ie93b7691b57ac6a8f86b3641ad07a1d54babcd42
For any messages that use CompositeBlock::getPermissionsError, include
details of the original blocks from which the composite block is made.
If there are any database blocks, give their IDs and also explain that
there may also be blocks due to IP blacklisting.
If there are no database blocks, then explain that the IP must be
blacklisted in multiple places.
Bug: T212326
Change-Id: Id6ad0019f8add4d5e000da5e872338e87cca485e
Create a CompositeBlock class which extends AbstractBlock and
adds the property $originalBlocks. This is for situations where
more than one block applies to a user/IP, and avoids the need
to choose just one of these blocks to enforce.
Behaviour of the resulting block is determined by combining the
strictest parameters of the original blocks.
Also add DatabaseBlock::newListFromTarget, which is similar to
DatabaseBlock::newFromTarget, but returns all relevant blocks,
rather than choosing the most specific one.
For tracking a CompositeBlock with a cookie, examine the
original blocks and only track the first trackable block that
is found.
Bug: T206163
Change-Id: I088401105ac8ceb2c6117c6d2fcdb277c754d882
