This fixes parameters returned by AbstractBlock::getBlockErrorParams,
but not those from ApiBlockInfoTrait.
Change-Id: I122017808766de1e9a9035f2f39a7b08607e56c1
Was reverted by I549810a4cd2e424cc4a438887d2f24614a24cc00 due to
T224607.
Original change by Vedmaka Wakalaka was
Ia0d840b772ea5f20c9594ce151cc57adc270e48b.
Original commit message:
The following methods should are factored out of the User class into PermissionManager,
leaving only deprecated stubs:
- User::isAllowed -> PermissionManager::userHasRight
- User::getRights -> PermissionManager::getUserPermissions
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::getGroupPermissions -> PermissionManager::getGroupPermissions
-User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
- User::getAllRights -> PermissionManager::getAllPermissions
Depends-On: I7909e9bd6bbfbd708c0a00b861a9b22a38c6665d
Bug: T218558
Bug: T223294
Change-Id: I8899240378f636ea70f447616710516c0a3c5c31
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
First iteration of adding a PermissionManager service as a replacement
for Title::userCan and User::isBlockedFrom methods.
- Created PermissionManager service
- Migrated Title::userCan to PermissionManager::userCan and deprecated the first
- Migrated Title::quickUserCan to PermissionManager::quickUserCan and deprecated the first
- Migrated User::isBlockedFrom to PermissionManager::isBlockedFrom and deprecated the first
Same for User::isBlockedFrom and PermissionManager::isBlockedFrom - the
$user parameter is now required so the declaration is changed from
isBlockedFrom( $title, ... ) to isBlockedFrom( $user, $title, .. ) which
means before User::isBlockedFrom removal all calls to it need to be updated.
Added PermissionManagerTest, it copies TitlePermissionTest but uses
PermissionManager instance instead of Title methods, this way keeping both tests
in place, we can ensure that nothing was broken and both are in working state
during the deprecation phase.
Bug: T208768
Change-Id: I94479b44afb3068695f8e327b46bda38e44e691f
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 is a theoretical issue where a passed in restriction does not match the
retrieved actions. There are no actions like this in MediaWiki core or known
extensions, but since the possibility exists, tests should exist to prevent
the issue before it happens.
Bug: T213220
Change-Id: I58da016768a3ee958baa2a25b8177a9e667fa955
To reduce the overhead of the block checks, return early if the user does not
have a block.
Bug: T216309
Change-Id: I14930fcb7987cbc83294497ab54fcfeeedc94bfe
This reverts commit 91fc748030.
Hence it reapplies I6312a36911e5b73d773452fefef7ff25b9af08a4.
The changes made by this commit are (excluding the cases
checked for earlier):
* An action can only be blocked if prevents() is true/null and
isBlockedFrom() is truthy. Previously, any action other than
'edit' or 'create' would be blocked if prevents() was true/null,
regardless of isBlockedFrom().
* If an Action can be constructed, and requiresUnblock() is
false, the action won't be blocked. Previously, requiresUnblock()
wasn't checked.
This commit was previously reverted because it exposed that
EditEntityAction::requiresUnblock in Wikibase wrongly returned
false (fixed in I99061230023da2bbd0f98190a2907ca2e9717a4c).
Other potentially similar cases were audited in T211048.
Bug: T208862
Change-Id: If74a1d422290b8c62b7a7a8922621c73c9598269
This reverts commit b1e4ca70b8.
Introduced a breaking change, and didn't follow the deprecation policy.
Bug: T210953
Change-Id: I11806165912d9188261d3c4c37dbae5cfd2865ec
Currently, not all actions are processed by User::isBlockedFrom(). This results
in users who are partially blocked from specific pages to be blocked from
moving and deleting all pages.
Bug: T208862
Change-Id: I6312a36911e5b73d773452fefef7ff25b9af08a4
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
The important part of the assertion is badaccess-groups, so we can drop the
other components and simplify the test code, plus also work around database
name issues that caused Travis CI to fail.
Bug: T206130
Change-Id: I137be892a611cd1f2d61baa77ad9528659587adf
It's still broken, and 4 days passed with broken Travis CI builds.
Re-reverting for now.
This reverts commit 589741b541.
Change-Id: I85a0b02d3f32303a90118e2705a7b2afc721cb57
Return existing errors instead of empty array in checkUserConfigPermissions().
Returning an empty array wiped out previously-found errors.
Also add test coverage for patrol action.
Bug: T206130
Change-Id: I2df0551c5837adc578b27082ab6ba2ac95d937f8
Let's see if they work now that services are reset between tests.
This reverts commit 7f843b0c04.
Bug: T201776
Change-Id: Iea7c74f8c77a97d83385b4399e500cf8129a1158
Previously it would affect all actions that use Title::userCan.
This used to be less noticable, but recently was expanded to include
the 'read' action. This only affected the case where both
$wgBlockDisablesLogin and $wgEmailConfirmedToEdit were enabled.
I don't think anyone was relying on the old behaviour as it was
undocumented, and only affected obscure permissions (checked with
Title::userCan and not depending on "edit" rights)
Follow-up b675be2083
Bug: T143790
Change-Id: I4ad93ed78de4f1ed444f73df6dc26d405a67e553
Also recognise MediaWiki: JSON pages (with the existing protection of
the editinterface right).
Bug: T76554
Change-Id: Idba166d82ee6dd507d7345c9bdbefc8ca78ed7b4
Blocks made for configured proxies, dnsbls, or the configured range
soft-blocks being added in I6c11a6b9 aren't real blocks stored in the
database. Let's actually flag these blocks as such and use a more
appropriate message when displaying them to the user.
Change-Id: I697e3eec2520792e98c193200c2b1c28c35bf382
This doesn't make sense because 'editcascadeprotected'
effectively gives you 'protect' rights.
Furthermore, no actual usecase was provided except for a testwiki.
This reverts commit da3464bada.
Change-Id: I655c1af8f418369c9551db86f24fb6b66c25afdd
Currently, both permissions are summarised in the protect permission. This is
unadvantageous for wikis that want to split this permission, for example for the
main page: They don't want protection changes by non-sysop users there, but on
transcluded pages some less privileged users are allowed to edit. Currently,
it is impossible to divide these permissions in a clean way (they can add a hack
depnding on action parameter in LocalSettings.php right now). Furthermore, an
additional permission is no pain, because by default it is handled the same as
protect until now.
Note that for sakes of backwards compability I decided to handle editcascadeprotected
as a subset of protect instead of removing all permissions to edit cascadeprotected
pages (and change the cascade protection state of a page) for users who only have got
the protect permission. Furthermore a different model would raise some strange questions
about the behaivour of the protection form for users with protect, but no editcascadeprotected.
Bug: T101309
Change-Id: I0734d6c26e75d7d7c01cf9750ad0315dd2c85bef
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
If we really need this we can do it in MediaWikiTestCase, next
to the setting of wgMainCacheType. But from what I can see the
code being tested here already doesn't use the old $wgMemc.
Change-Id: I9e4b2109b2f3c18d8d5551bbadae5711c1d4c0a6
Block::__construct now accepts an array of options instead of a myriad
of optional parameters.
Also add a test for the old constructor.
Change-Id: I6ccd4df569ab49ad841a1ad591e23cafb1715841
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
* Refactored getUserPermissionsErrors "expensive" checks flag to be
a bit more general.
bug: T51419
Change-Id: Ic1882aa2957eed2b978761b5fc34ea9bdd8981b5
* AbortMove hook is removed in favor of two more specificly focused
hooks: MovePageCheckPermissions and MovePageIsValidMove.
** MovePageIsValidMove is for extensions to specify whether a page
cannot be moved for technical reasons, and should not be
overridden.
** MovePageCheckPermissions is for checking whether the given user
is allowed to make the move.
* Title::moveNoAuth() deprecated
* Title::moveTo() deprecated
* Title::isValidMoveOperation() broken down into
MovePage::isValidMove() and MovePage::checkPermissions().
* Title::getTitleProtection() is now public, and returns
unprefixed fields
Change-Id: Ic5026384b92a0d68d628397ffe1de6e5b6183f02
This test fails on non-English MediaWiki setups. Yes, the solution
looks kind of hackish, but a proper solution would require major
refactoring of a lot of core classes. Please let us introduce this
quick fix for now.
Change-Id: I0e4fdaca5e7f844f45a2c41572e2e839640714b6
In permission error messages that can be displayed for multiple actions,
add a parameter indicating which action was attempted. This allows
fixing confusing messages such as "You can't edit this page" when a user
tries to move a page that they can edit but not move.
Bug: 40145
Change-Id: Ib4b75d8b1e0db96fe8a58f7343b0b2811fd19682
