This adds MediaWiki\Watchlist namespace to the classes of watchlist
directory and adds deprecation notice since 1.43 to the just created
unnamespaced aliases of the classes.
Bug: T353458
Change-Id: I4234f8fe62bb3bde6f5271c7ba31a2420b0f4b90
Why:
* Before this task, when an API parameter specifies allowed user
types, temporary users and permanent users are in the same
category: 'name'.
* However, it is useful to separate them out, and sometimes
allow a permanent user but not a temporary user (e.g.
ApiResetPassword, since temporary users don't have passwords).
* We therefore re-defined the 'name' type only to refer to
permanent (named) users, and add a new 'temp' type.
* This fixes params that currently intend to allow temp users,
and that use 'name' to do so, by adding 'temp'.
What:
* Based on a search for `UserDef::PARAM_ALLOWED_USER_TYPES`,
add the 'temp' type where necessary.
* The following were not updated, because they shouldn't apply
to temporary users:
- owners for includes/api/ApiQueryWatchlist.php,
includes/api/ApiQueryWatchlistRaw.php
- users for includes/api/ApiResetPassword.php,
includes/api/ApiUserrights.php,
includes/api/ApiValidatePassword.php
Bug: T350701
Change-Id: If5ccf1d469327791acff74d013343307e411cca9
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
Report what the block actually does, rather than what was requested,
since these might not always match. E.g. a request to hide an IP
address may result in a block being made that does not hide the IP
address.
Bug: T343749
Change-Id: Iebe62179cfc77835dca78ac672f9ba3edfadbfed
These three classes:
- TitleArray
- TitleArrayFromResult
- TitleFactory
We need to move these and the rest of files under title/ to Title/ (and
namespace them) but the patch will become way too big given that Title class is
also one of them.
Bug: T321882
Change-Id: Iac1688172ee457348a08a470c86e047571feb8e0
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
PHP 8.1 will give us "first class callables" that look like e.g.
$result = array_map( $this->fn(...), $array );
For now we can use
$result = array_map( [ $this, 'fn' ], $array );
Change-Id: I7278c80c075d162da73aa45af1b6578310ce0624
Defer to the TitleDef type definition for page titles to validate values
passed to the pagerestrictions parameter.
Bug: T279689
Change-Id: Ia2e116d1bc476b178d85a6331dec17d7a8df74ba
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
I believe it does not make sense to go on with peripheral action when
the primary action did not succeed.
If the blocker decides to attempt the block again, they can also decide
whether to add watch or not at that time.
Change-Id: I64880ce254e33378642bb9f1952c88ce490ef490
In SpecialBlock, ignore restrictions if the 'sitewide' radio was
selected. In ApiBlock, ignore restrictions if the 'partial' parameter
was falsey.
In both cases, ignoring restrictions means not passing them to
BlockUser.
This restores the behaviour prior to a656d03597, that a block is
sitewide unless it is marked as partial, even if restrictions options
are set.
Bug: T189073
Change-Id: I4d2e08b744b9d59909ce24cc5f167b676478970d
Pass 'partial' parameter from ApiBlock.
Pass 'DisableEmail' parameter from SpecialBlock only after confirming
it is set.
Follow-up to a656d03597
Bug: T189073
Change-Id: I5acbb1c5d49b216bb235936cd479829128beac77
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
Refactor this method to make clearer that it returns the return value
of AbstractBlock::parseTarget and does nothing additional when called
without a WebRequest.
Update callers that do that to call parseTarget directly instead.
SpecialBlock::getTargetAndType (added in 97e2c97578) predates
AbstractBlock::parseTarget (added in f64f960d9a). The callers being
updated here called getTargetAndType since before parseTarget was
available.
Bug: T250940
Change-Id: I366e1076b10ab7c2dc4bb04920908b3286b77b73
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
$wgBlockCIDRLimit states how large rangeblocks are allowed to be for IPv4
and IPv6. The API now calls SpecialBlock::validateTarget() to perform
that validation step.
As a minor thing, SpecialBlock::checkUnblockSelf() is now called twice by
the API, but that can probably be cleaned up at another time.
Tests included.
Bug: T199540
Change-Id: Ic7d60240d9ebd9580c0eb3b41e4befceab69bd81
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
Fixes unintended breaking change made by I84ed21641c44b2f65ebe.
ApiQueryUserInfo::getBlockInfo() is restoed as a hard deprecated stub.
This renames the method in the new ApiBlockInfoTrait to
getBlockDetails.
Depends-On: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
Change-Id: If47a93878f87d69800e5f305404c22528dac5e94
ApiBase directly uses this method causing a cyclic dependency between
ApiBase and ApiQueryUserInfo
Change-Id: I84ed21641c44b2f65ebe1980b0893d1846db3b34
The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
Use getters and setters for $mReason, $mTimestamp, $mExpiry and
$mHideName; use Block::getType to check if a block is an autoblock
instead of checking $mAuto; no change needed for $mParentBlockId,
which is not accessed externally.
Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
This adds a UI for blocking namespaces to Special:Block
and a namespacerestrictions parameter to the block API.
The number of namespace restrictions in a single block
is not limited as page restrictions are.
The checkbox allowing the blocker to specify whether
the target can edit their own user page is normally
disabled for a partial block, but is re-enabled if
the block is to the user talk namespace.
If the config $wgBlockAllowsUTEdit is set to false, the
checkbox will not appear, and the target will not be
able to edit their own user talk page if they are
sitewide-blocked, namespace-blocked from the user talk
namespace, or page-blocked from their user talk page.
Bug: T204986
Change-Id: I9e231ad109d7285486ec332b26780339592b8df7
If partial blocks are available but a sitewide block is being made,
$params['pagerestrictions'] is null and implode() raises a warning.
Since null casts to the empty array, it's easy enough to work around.
Also add a test hitting this case.
Change-Id: Id7e2559d7569031b7c1228adb0c0a14b3c1527c3
Make the necessary UI changes to Special:Block in order to set/update
partial blocks.
Bug: T197109
Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
The code coverage tool still reports that line 50 ("$status,") is not
covered, but this is just a parameter to a function that is in fact
called and does show up as covered, so I'm pretty sure it's a bug.
I replaced a couple of sanity checks that reported "incomplete" on
failure with actual assertions so that the test would fail properly if
the sanity check failed.
The testing could still probably be expanded considerably.
Change-Id: Ib6ba7227af23bcb50c7e3bafb0b51395e8acf03f
