Instead, go back to validating the individual values so one invalid name
doesn't cause the whole module to error out. The code for that was all
still there, just unused since Ic67fb540.
Bug: T142895
Change-Id: Ia5eae51d69185580ac2c772afc198a92813e407a
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
The API 'user' type accepts both user names and IP addresses, and
applies normalization but not canonicalization. We should be using this
on basically every user parameter to ensure that e.g. IPv6 usernames get
uppercased.
Bug: T122803
Change-Id: Ic67fb54061ac311e54f325b2a1a4658f43b8fef4
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+users-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: Ic467e2edc130018c61a30c61864f1f0de89540ff
Mysqli is returning SELECTed ints as strings rather than as ints, I'm
guessing to avoid problems with 64-bit int types on 32-bit systems. PHP
mostly doesn't care, but it causes API JSON output to have strings
instead of ints all over the place.
This also fixes ForeignAPIFile::getUser( 'id' ) returning the user
*name*.
Bug: T98276
Change-Id: Ie6591d72b3ac40172f8176a8ca8b6fad8e9275a5
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
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
This change affects list=allusers, list=users
and meta=userinfo.
Note: This change also add block expiry to meta=userinfo.
Unlike this field in other modules, it formats the timestamp
properly, instead of just dumping db contents.
Resurrecting from abandoned change Ifdeac5c5f547
Bug: 63326
Change-Id: I4b3e55fe2d07271e1ded89d36d0b98de0e643177
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
Blockinfo is currently the only piece of information
(apart from tokens) in the users API which might change
depending on the permissions of the user making the
query. There is no point in making the API request
uncacheable if blockinfo is not requested.
Change-Id: I533f622b7d9077589f148fbb6de98b15ef1c212a
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
Fixed a little documentation issue, removed a line of unreachable code
and fixed up two formatting issues in the process.
Change-Id: If29391ee1a0daf19973437f36c3216b8716debd0
The docs comment says it returns an int but it often returned a string.
This led to casting this value into an integer in other parts of the
codebase and in extensions (grep MobileFrontend or Echo for EditCount).
Bug: 51633
Change-Id: I6fe5b26c24e674e8148c1fd278774b3fabe844c5
SpecialPage::getContext called and $mContext is null. Return
RequestContext::getMain(); for sanity
Change-Id: Ie0ed360835164e8a4eb1c675ec8edd944ab95898
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
I've fixed several PHP notices and the problem that rights returned
by User::getRights() might have duplicates if altered by a hook
(same for User::getEffectiveGroups).
Change-Id: Id92af387d8c09414076bac40e83052cd6f913f42
Made action=query&list=users use User::getRights() if
usprop rights given. This not only removes redundant
code, but makes it execute the UserGetRights hook, so
that this now includes rights given by Extensions (eg.
CentralAuth does that).
Patch Set 2: Modified the User class to be able to
inject further data into User::newFromRow() and using
that to inject the groups taken out of one SQL query
(for performance reasons). Furthermore I've split up
the query in ApiQueryUsers.php into one for user data
and one for the groups, to only have one row for each
user.
After all the perfomance of this should now be ok, not
extremly good, but bearable (though I couldn't test it
deeply, as I don't have much data in my CentralAuth
environment).
Change-Id: Ie5b2924abb82ac254c77e1d04cc4d5b308962dad
No need to duplicate the code of User::getAutomaticGroups() in
ApiQueryUsers::getAutoGroups(), instead just call that method
directly.
Also deprecated the latter in favour of the former and replaced
all calls in core.
Change-Id: I224cb610cbd6a927a4c7f7137951416368f8cb5d
On a stock install, the autoconfirmed requirements default to zero, so
anons qualify for autoconfirmed. They don't actually get it because
User::getEffectiveGroups() only checks for autopromote groups for
logged-in users. However, ApiQueryUsers::getAutoGroups() (which
duplicates this logic for some reason) didn't use the same rule and
applied autopromote groups to anons too, which caused discrepancies
betwen the API output and wgUserGroups.
Krinkle noticed this because a QUnit test for mw.user.getGroups() was
failing while logged out: the API response included autoconfirmed but
wgUserGroups didn't.
Change-Id: I0b781c11e06d3cc7176b2fb3ba06979d3637f970
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
