Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
This is useful for use cases such as T272412, which allows any user
to see all their info via their preferences.
Bug: T275441
Change-Id: I99e576bd9ad3980ee0fa8397409ef0c7e248a175
isset() does two things: It checks if a variable (or array element)
is declared, *and* it checks if it is null. If a variable is null,
isset() fails as if the variable was not set. All these additional
null checks are dead code.
Change-Id: I71e8cc26dac839c9d081bf00b4164b7b5147e586
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This method was removed (I84ed216) before the Block class was
refactored (I83bceb5) and restored (If47a938) after the refactor.
After the refactor, this method should accept and AbstractBlock,
so it can handle a SystemBlock as well as a database Block.
Change-Id: Ice8a2e7c19e88406229bd836a45f377abdb72fb6
Fixes unintended breaking change made by I84ed21641c44b2f65ebe.
ApiQueryUserInfo::getBlockInfo() is restoed as a hard deprecated stub.
This renames the method in the new ApiBlockInfoTrait to
getBlockDetails.
Depends-On: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
Change-Id: If47a93878f87d69800e5f305404c22528dac5e94
ApiBase directly uses this method causing a cyclic dependency between
ApiBase and ApiQueryUserInfo
Change-Id: I84ed21641c44b2f65ebe1980b0893d1846db3b34
The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
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
The ApiQueryBlocks and ApiQueryUserinfo endpoints will now return whether or not the block is
sitewide or partial. Partial block restrictions can be returned with ApiQueryBlocks.
Bug: T197141
Change-Id: I76eb4cac4dc989c621a00a39996faebd0eb9892c
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
This has a number of implications:
* A deprecation warning is automatically generated if the value is used.
* action=paraminfo can list it in a machine-readable manner.
* It is automatically flagged in the help when message-per-value mode is
used.
* In values lists in the help, it's specially marked (currently
strike-through).
* ApiSandbox will mark it in the widgets (currently strike-through).
Deprecation of submodules is not automatically detected here, that's
left for a later patch.
Bug: T123931
Change-Id: Idad6377063e457f9352a99df5c7cc15b1563579e
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
This allows for removing $wgContLang from many API modules where it was
only used to call $wgContLang->formatExpiry() in a way in which the
results don't actually depend on the language.
Change-Id: Ib0f25f288b9b87d2e4131297c552e5971696db87
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
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
This query / logic has been extracted from
ApiQueryUserInfo.
Unit & Integration tests have also been added.
Relating to the task linked this is the last change
needed in this ApiQueryUserInfo!
Bug: T129482
Change-Id: I91aa109416c16cd1f257c9de46669e35d6fd34d7
meta=siteinfo gets a list of all configured central ID lookup providers
and which one is being used as the default, while meta=userinfo,
list=users, and list=allusers get the ability to return the IDs and
attachment status.
Change-Id: Iea15b6c22baac79b3f8ca6df0e20a6a4299507d2
Use message-per-value for message
apihelp-query+userinfo-param-prop to allow smaller strings
for translation.
Each prop in a message also will show up a new parameter on the help
page without the adjust of the translation (but than in english instead
of fully skip it).
Change-Id: I7bb36e4fd95e68fe4798e31070b6fa05ac550d38
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
