This used to be needed when we couldn't pass a cross-wiki
user target correctly. Now that UserIdentity is cross-wiki-aware,
we can.
Bug: T283642
Depends-On: I6f57357d3a73e753e018986e6af6245c29468875
Depends-On: Ie48ee3fcbf3fa7a285e80caf627be0b726b757c2
Change-Id: I3c21e55022c5fb316a390027f7c28211b29c3d62
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 is no longer needed in Wikimedia production. Third
party users will have had a release to adjust to one of
the three called-out migration issues. It's time.
Bug: T277987
Change-Id: Ia4a797afc71441ed9a7a90ff4f1e72cc4495cf63
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
Code that needs to store an actor ID in the database to
represent a UserIdentity, or needs to construct a UserIdentity based on
an actor ID loaded from the database, should use the ActorNormalization
service.
Note: The getActorId() method is removed from the UserIdentity interface,
but all concrete classes continue to support it for now.
UsererIdentityValue::getActorId() is hard deprecated and should
be removed in 1.37. It always returns 0.
User::getActorId() is not deprecated at this point.
Bug: T274179
Depends-On: Id2b3ddf6a2a7cdf90f8936a69148d2cce6fde237
Change-Id: I9925906d11e47efaec3c1f48d5cb3f9896a982c1
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
This includes fixing some mistakes, as well as removing
redundant text that doesn't add new information, either because
it literally repeats what the code already says, or is actually
duplicated.
Change-Id: I3a8dd8ce57192deda8916cc444c87d7ab1a36515
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
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
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
The new service replaces the following public DatabaseBlock methods:
* ::delete
* ::insert
* ::update
* ::purgeExpired
Bug: T221075
Change-Id: I5f95db14b1189fd62d2c2bd5dae2cab0a368f401
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
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
This happens because DatabaseBlock::initFromRow didn't
cast all database-loaded variables to boolean.
Bug: T251048
Change-Id: I0c328b7d06fd911d67a9744253e005902a6aa136
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
When there is only one entry but it was found twice, the query became
'ipb_address IN (a, a)' instead of 'ipb_address=a'.
Change-Id: If6c49ad1502c1ba277fb83b64757fd16f0886093
DatabaseBlock methods for handling block cookies are deprecated, so
stop using these methods in tests and throw warnings.
Change-Id: I2b5cfd579aa14bbfc7a292587a288ee5032eb5ab
The block reason will be stored in the database and displayed to users
in all kinds of languages, so it doesn’t make sense to localize it in
whatever the blocking user’s language happens to be.
Bug: T238570
Change-Id: I5f30cf6499f0d380eb0d5336c93190affc93d6f9
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
Autoblock reasons are built as a Message which takes the original
block's reason as a parameter. If the autoblock's reason is set using
the Message, it will be stored in the database with templates
expanded due to how a CommentStoreComment is constructed. Instead,
set the autoblock reason using a string with the unexpanded template.
Follow-up to 6a8920d3, which fixes how the reason is displayed in the
UI, but still expands the templates on saving.
Bug: T236501
Change-Id: I67a9941a9c039331576cbfc2ab58d9f20a7213e2
