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
assertEquals( false, … ) still succeeds when the actual value is 0, null,
an empty string, even an empty array. All these should be reported as a
failure, I would argue.
Note this patch previously also touched assertSame( false ). I reverted
these. The only benefit would have been consistency within this codebase,
but there is no strict reason to prefer one over the other. assertFalse()
and assertSame( false ) are functionally identical.
Change-Id: Ic5f1c7d504e7249002d3184520012e03313137b4
The mock timestamp is asserted via $prev, which is set a few lines
up.
The input timestamp is set as 0, which usually passes (if these two
lines execute in the same second), but when the two lines of code
are on opposite sides of a clock second boundary, the test would
fail.
Instead of fixing the setTimestamp() call, remove it in favour of
fixing the 'timestamp' option instead, which was needlessly
being set to one thing and then overwritten by setTimestamp.
Bug: T231166
Change-Id: If6a1e4ec7b91efee0a43e6dd86794f15c5a440b3
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
