Replace all uses of AbstractBlock::getTarget with
Block ::getTargetName and ::getTargetUserIdentity.
Create AbstractBlockTest and two test cases for
AbstractBlock::getTarget and ::getTargetAndType.
It tests triggering of the deprecation warning.
Bug: T282247
Depends-On: I0543f363af66c57f5763b91320d87a69f23f9466
Change-Id: Iaeca824cac30172178de72f3cf7b7ae4cdd6f880
In order to allow Authority to know about user blocks,
we need a narrow interface to represent such blocks.
This deprecates some methods on AbstractBlocks in favor
of new methods on the Block interface that avoid binding to
the User class.
Bug: T271494
Change-Id: I7bb950533970984a014de0434518fbbefb695131
This adds a new type of block restriction for actions, which extends
AbstractRestriction. Like page and namespace restrictions, action
restrictions are stored in the ipblocks_restrictions table.
Blockable actions are defined in a BlockActionInfo service, with a
method for getting all the blockable actions, getAllBlockActions.
Action blocks are checked for in PermissionManager::checkUserBlock
using DatabaseBlock::appliesToRight. To make this work, this patch
also removes the 'edit' case from AbstractBlock::appliesToRight,
which always returned true. This was incorrect, as blocks do not
always apply to edit, so cases that called appliesToRight('edit')
were fixed before this commit. appliesToRight('edit') now returns
null (i.e. unsure), which is correct because it is not possible to
determine whether a block applies to editing a particular page
without knowing what that page is, and appliesToRight doesn't know
that page.
There are some flags on sitewide blocks that predate partial blocks,
which block particular actions: 'createaccount' and 'sendemail'.
These are still handled in AbstractBlock::appliesToRight, and are
still checked for separately in the peripheral components.
The feature flag $wgEnablePartialActionBlocks must set to true to
enable partial action blocks.
Bug: T279556
Bug: T6995
Change-Id: I17962bb7c4247a12c722e7bc6bcaf8c36efd8600
Creating any block class includes a call to AbstractBlock::setTarget
which uses MediaWikiServices, meaning that no blocks can
be created in unit tests. If the target is an empty string '', set
the target and type to null instead of using the BlockUtils
service, which would eventually set them to null but would require
using MediaWikiServices
Allows moving SystemBlockTest to a unit test
Change-Id: Icdf10a6b89aef1995b6e5b5cee9ba5dd5593b01e
System blocks (which tend to be against IP addresses) can apply to
anon users only, or to logged-in users too. This differs depending
on the type of system block.
This is enforced in BlockManager::getAdditionalIpBlocks by checking
whether the user is anonymous before constructing a given type of
system block. Before this commit, it is not codified in the block's
properties, meaning that there is no way to communicate via the
API whether the block blocks logged-in users too.
Database blocks have a property $isHardblock; move this up to
AbstractBlock, so that system blocks and composite blocks can set
this property too.
Bug: T261639
Change-Id: I4f6ddf6cca6e01e85c56eef1ca7496dd6fcf52e6
Along with AbstractBlock::shouldTrackWithCookie,
the following DatabaseBlock methods were removed:
* setCookie
* clearCookie
* getCookieValue
* getIdFromCookieValue
* shouldTrackWithCookie
All appear to be unused
Change-Id: Ia42ffd7b4688d83c1647e61ed018ed70587f30d0
Rather than having to do DatabaseBlock calls directly,
and then ManualLogEntry calls to facilitate logging,
let's create a BlockUser service, capable of blocking users
and logging, optionally with permission checking.
This should make blocking users easier for developers,
for instance, AbuseFilter or CheckUser can easily
benefit from this commit.
Bug: T189073
Change-Id: Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab
Going through some more abstract classes in core, and
marking those that are extended by extensions as
stable.
I have limited knowledge on the uses of these classes so
marking for vibisility/review.
Bug: T247862
Change-Id: I1939bb11038ec2536eebbdbd12524e83d615b86b
parseTarget is documented as accepting an int as the $target param,
but it will always treat it as a string. Any int would be interpreted
as the user name (string)$target, and any caller passing user names
would be passing a string, since most user names can't be expressed
as an int.
This fixes the documentation to allow only string or User.
Change-Id: I3dd20b91bbe8da7fee67bd336c7e973a22cf082d
The motivations behind this change is T227892 and that a blocker for a System or
Composite block provides no useful information for the end user.
Here is what's changing:
* Move the $blocker property to DatabaseBlock, since this is the only type of
block that can be created by a user.
* Move handling of the 'by' and 'byName' constructor option from AbstractBlock to
DatabaseBlock.
* getBy(), getByName(), are now abstracts methods and each block type have to provide
their own implementation
* getBlocker(), setBlocker() are being deprecated in AbstractBlock and moved as internal
methods into DatabaseBlock
Bug: T227892
Depends-On: Ie2aa00cfec5e166460bcaeddba3c601fe0627c13
Change-Id: I1b17c652b12d98de3d996d309d4d3f22074be411
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
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
The target and type of a block can theoretically be set to null via
AbstractBlock::setTarget, which calls AbstractBlock::parseTarget,
which can return null for the target and type.
Change-Id: Id8ec4ad6ff8f73b475793bb47ca95227ac2085e1
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
Several block-related hooks allow the user to be put into in a state
that is inconsistent with blocks that can actually be made:
* With UserIsHidden, User::mHideName can be set to true without there
being a block
* With UserIsBlockedFrom, a user can be blocked from editing a page
without there being a block
* With GetBlockedStatus, public block properties can be arbitrarily
set on a user
These problems are mostly theoretical, but mean that it is impossible to
make some basic assumptions, e.g. that a user who is blocked from a page
must have a block. The hooks are not widely used, and with a few changes
we can make them more robust so such assumptions can be made.
This patch:
* Ensures UserIsBlockedFrom is only called if there is a block. This
would be a breaking change if any extensions were using this to block
an unblocked user; the intended use case is clearly for extensions to
allow user talk page access to blocked users.
* Adds a new hook, GetUserBlockComplete, which passes the block for
modification. This should be used instead GetBlockedStatus and
UserIsHidden, which will be deprecated in the future.
* Allows the 'hideName' option to be passed into the AbstractBlock
constructor so that suppressing system blocks can be made.
Bug: T228948
Bug: T229035
Change-Id: I6f145335abeb16775b08e8c7c751a01f113281e3
Public methods for checking and setting these properties already
exist where needed. Also update the remaining direct uses of these
properties in core.
Change-Id: Icdef025c9700e625aeb2a07975e69f1b1cc2466c
This fixes parameters returned by AbstractBlock::getBlockErrorParams,
but not those from ApiBlockInfoTrait.
Change-Id: I122017808766de1e9a9035f2f39a7b08607e56c1
Move the cookie blocking logic into one place. Specifically, move
these methods to the BlockManager:
* User::trackBlockWithCookie
* DatabaseBlock::setCookie
* DatabaseBlock::clearCookie
* DatabaseBlock::getCookieValue
* DatabaseBlock::getIdFromCookieValue
* AbstractBlock::shouldTrackWithCookie
After this, BlockManager::trackBlockWithCookie should be called to
track a block, and BlockManager::clearBlockCookie should be called
to unset the cookie. The other methods in the above list are
helper methods that are made private or marked internal.
Also update places in core that call User::trackBlockWithCookie to
BlockManager::trackBlockWithCookie
Bug: T225141
Change-Id: I818962c6932c01c841a549a101637e00a7593e48
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
This anticipates I83bceb5e5, which refactors Block into different
classes: Block (for blocks stored in the database), SystemBlock
(for temporary blocks), and AbstractBlock (the parent class).
Block should be become a deprecated alias of DatabaseBlock.
This adds an empty AbstractBlock parent class, and makes Block
extend AbstractBlock, but leaves it otherwise unchanged. This is
to allow typehints to be updated, to avoid a breaking change.
Bug: T222737
Change-Id: I3cf78cf77ccf492dadf53e479f81891961021469
