Expected value is the first parameter to assertSame() or assertEquals().
And turn to use assertCount() for some assertions aginst count of array.
Based on code search `assert(?:Same|Equals)\(.+,.+expected` and I look
through files roughly, so some assertions that don't contains 'expected'
are also fixed. In the meantime, some assertions that I am not clear
about are not touched.
Change-Id: I75798b60d29fd19b33f4fdf34ed3c788db420d01
Changes from patch set Icb93c79f4843b59dae80d3eda1a880457a1a68f2
Also some swaps from assertEquals to assertSame/True/False/Null
Change-Id: Ife497ae6cb1888b77eb25e85b76df72adc65641a
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
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
Instead of using AbstractBlock::parseTarget, which
just calls the BlockUtils service but makes it impossible
to convert the tests to unit tests
Follow-up will actually convert the tests to unit tests
Change-Id: I939c44811669e7a09dcffc7589e3b1176a2f68d4
This reverts commit 900c6663b0.
Reason for revert: breaks Parsoid CI. Instead of fixing the test in presence of the FlaggedRevs hook, I would rather convert DefaultPreferencesFactory to Authority and fix the tests once instead of doing it twice.
Change-Id: Iaa440a9804c9ed97339e737162ef64ccf29ceb51
* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
The problem was that when using $user->getBlock
within checkCondition (APCOND_BLOCKED) caused a infinite
recursion as calling getBlock eventually leads back to checkCondition.
The fix here is to stop using userHasRight as that is the cause of the recursion.
This also fixes testGetUserAutopromoteBlockedDoesNotRecurse test so it
shouldn't fail.
Bug: T270145
Change-Id: Ic751eba70730de286bbd55772bd7562459fb30b4
Some User methods fail if they are called before $wgRequest is
set. But according to the Setup.php comment, it is only set for b/c.
The global request object can be lazy-initialised at any time.
This is sufficient to avoid T263911 (loss/obfuscation of the $wgServer
error message).
In tests, try to keep $wgRequest and RequestContext::$request in sync.
Introduce MediaWikiIntegrationTestCase::setRequest() which sets both at
once, and use that instead of setMwGlobals() or direct assignment.
BlockManagerTest was accidentally exploiting the fact that the global
context request and $wgRequest were separate objects. Making them the
same causes session cookies to appear in the response, breaking the
cookie counts. Use a new response for the test.
Bug: T263911
Bug: T245940
Change-Id: I2be99f7251a837bc6b62be0b152038157dec10f2
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
Also soft deprecate the old function. Replacing usages will be done
in a follow-up patch.
Bug: T263327
Change-Id: Iffa9337f3c5bd198693fdf51be55c4b1ecfacaf6
Following 23c3c70d7f, soft deprecate the static methods on
DatabaseBlock that have been moved to DatabaseBlockStore:
* ::insert
* ::delete
* ::update
* ::purgeExpired
Update calls to the deprecated methods from core.
Change-Id: I1272eb978594fd4f386bda12cbc24131ad7d882f
Create UnblockUserFactory service, which returns an UnblockUser.
UnblockUser::unblock replaces SpecialUnblock::processUnblock, which
is now deprecated.
Update SpecialUnblock and ApiUnblock to use UnblockUser, removing
the API module's dependency on the special page.
Update SpecialUnblock::processUIUnblock to use UnblockUser, and mark
it for internal use only. It now returns a Status object.
Also add BlockPermissionChecker::checkBasePermissions, which checks
for the 'block' right and the 'hideuser' right if necessary.
Bug: T250020
Change-Id: Ide31da469297f4582ad0e3f7f1a7c40d542923f8
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
This intentionally doesn't change the usages of SpecialBlock
method nor does it mark it as deprecated, because that is planned
to be done in follow-up patches:
* Ide31da469297f4582ad0e3f7f1a7c40d542923f8
* Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab
Bug: T189073
Bug: T251861
Change-Id: Ib230f1cdb745937fac7512924f1d79e7b3542ab0
Done with `composer fix` and suppressing the rest (i.e. sniffs for
global variables, which for core should be suppressed anyway).
Additionally, add `-p` to `phpcbf`, as otherwise it just seems stuck.
Change-Id: Ide8d6cdd083655891b6d654e78440fbda81ab2bc
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Deprecate deleteIfExpired, chooseBlock and fromMaster, which are
unused.
deleteIfExpired, called internally, appears unused since
b3c844133a.
fromMaster, an internal getter/setter for the mFromMaster property,
is unused since newLoad was refactored in
a387a375a1.
chooseBlock is unused since the introduction of CompositeBlock in
1eaf65d0a5.
Change-Id: I9db6d989e3138b3e0cbf6315ecbf2f8793a37bd6
This should be the exact same. Its more a style change than anything.
So why do it then?
* I believe this is much less confusing than code mentioning a weird
"standard class". Barely anybody knows what this is, and what the
difference between "object" and "stdClass" is.
* The code is shorter.
* It's even faster. In my micro benchmark it's twice as fast.
Change-Id: I7ee0e8ae6d9264a89b6cd1dd861f0466ae620ccc
