When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
* In PermissionManager, if a user is anonymous but temporary user
creation is possible, grant elevated permissions at RIGOR_QUICK rigor
level. This is mostly to make skins show "edit" instead of "view
source" to anonymous users in the recommended permissions
configuration.
* Present temporary users as if they are not logged in in various places
in the interface: create/move permissions errors, login, preferences,
watchlist, BotPasswords, ChangeEmail, ResetTokens.
* Show a warning on login/logout about loss of access to the temp
account.
* On login, don't show the temporary name as a suggestion for the login
username.
Change-Id: Id0d5ffa46c3ca5c7b30d540cedbaa528b682aa85
There are common use cases to having a group inherit permissions from
another group. For example, if you have to have a "confirmed" group that
can be manually handed out to grant "autoconfirmed" status, or if you
wanted to make the "sysop" group also have "interface-admin" powers.
Previously to make this work you needed to either copy all the
$wgGroupPermission entries for the second group, or use a
$wgExtensionFunctions to copy it over at runtime. Neither are great
solutions, hence this patch.
This introduces a new configuration option, $wgGroupInheritsPermissions,
that GroupPermissionsLookup will use when determining what permissions
each group has. This option is not recursive for simplicity.
To make this work, Special:ListGroupRights now consults
GroupPermissionsLookup instead of looking at the
$wgGroupPermissions/$wgRevokePermissions globals. It also uses
UserGroupManager to get the list of all groups instead of looking at
more globals.
Anything still directly reading permissions from those globals is liable
to be broken, if they weren't already.
Bug: T275334
Change-Id: Iad72e126d2708012e1e403bee066b3017c16226d
The concept of a redirect chain didn't really work for a value of
max redirect > 1. In the ideal world, we just want to have a source
which points to target (source -> target) discarding the concept of
a redirect chain completely.
Having something like: source -> target -> target1 -> target2 doesn't
really work well with the current database design.
NOTE: Support for $wgMaxRedirect will be removed soon hence
deprecation without interfaces for replacement.
Bug: T290639
Change-Id: I469de6f85e405e8ddbe7abaa5b99b77cb9cf415d
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
This is the default anyway when using ->with(). The test code
becomes so much more readable without this, I would like to
argue. Let it just say "with these values".
Because of the way I split my changes into multiple patches
there are a few other changes in this patch I could not split,
e.g. removing unnecessary ->any(). This is the default anyway
and doesn't make the test more specific.
Change-Id: I34990799fa9258ba8dc64c7e78ec43f7903b7681
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
In order to break up cyclic dependency between UserGroupManager
and PermissionManager, introduce a lightweight service for checking
group permissions.
Bug: T254537
Depends-On: I99ab3a69c41b3ec6721f9504ad6c77d3122df591
Change-Id: I1acd55c07d07b4a0d43fd838e11374b6d9be98d9
