Add restriction support to LoginSignupSpecialPage::__construct,
and set mRestriction to 'createaccount', removes the need to
inject a PermissionManager
Change-Id: Ifd7d6e687a3c78d300cc612526458afb6934a4c0
In a few places where a PermissionManager is used
but only GroupPermissionsLookup is needed
Also update references to the class in PermissionManager
that referred to it as GroupPermissionLookup
Change-Id: I5d7a13900852a38768a106aeee1ce012c3a04ea2
This patch injects services into WikiImporter. It also adds
a WikiImporterFactory service for creating WikiImporter
instances.
Change-Id: I2966297e5728fca1ae8280361f1008cef6c6041b
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
The getRestrictedPages() is completely unused in Codesearch, and I
can't think of a use case for wanting to list all but only pages
other people don't have access to.
Wanting to know this about any given page seems useful, but that is
what SpecialPage::isRestricted and ::userCanExecute are for.
Change-Id: Ie1d8796e793170beec516e8b1e4a3519c0e18890
Since 2011, FileDuplicateSearch has been especially awkward as a
QueryPage subclass. The only thing of value in the parent was
construction of <ol></ol> tags, but that's not enough to justify it.
getQueryInfo() was unused -- my motivation is to not have to maintain
it. A LoadBalancer was injected but was unused.
Change-Id: I2f0c18913260ee74ef266352bb93cfbdc1143d85
User::getBoolOption() is deprecated and should be replaced with UserOptionsLookup::getBoolOption()
Bug: T277600
Change-Id: Ife3c721237258d50852bbf764def74657cc70428
When extensions add fields with help messages to the signup form,
e.g. on https://wikitech.wikimedia.org/wiki/Special:CreateAccount,
there was no margin between the help message and the next field.
Remove a workaround for this problem from the password help message.
Follow-up to 1d82384bb5.
Change-Id: I07ad85d3b13697d360206d32b2861d1ee2a62132
If a special page is no longer expensive (by code or by config like
DisableQueryPages) the data should not longer stored in the database,
because always fresh data are shown and never the cached data
This does not delete on disabled query pages, because the data still
visible on the page.
This only affectes query pages and not very special pages like
ActiveUsers
Bug: T174513
Change-Id: Ia9015cb7bc0ab7b1a3d96d1b481c31b3e6c39657
