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 existing query only works with a single value for augroup, or mostly
if it's combined with auprop=groups or auprop=rights (since most users
don't have every possible group).
When used with multiple values for augroup, it will raise an error if it
happens to encounter enough users who have more than one of the
specified groups. And further, it will lead to repeated groups for these
users if combined with auprop=groups or auprop=rights.
To avoid both these issues, let's use EXISTS instead of a JOIN to test
augroup. While auexcludegroup doesn't have this problem, we may as well
make the same change there, too. And doing that, there's no reason to
continue with an error when both augroup and auexcludegroup are used.
Bug: 70496
Change-Id: Ia7086ce87012c22651ac4c7a3f75558347276226
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
The query introduced to support the auactiveusers is itself broken (it
counts every edit multiple times when combined with the group filters or
auprop=groups or auprop=rights, or for users with multiple rows in
ipblocks) and it breaks auprop=groups and auprop=rights.
Instead, let's filter using the same cached data used by
Special:ActiveUsers and do the actual counting of recent "edits" in a
subquery. And for parity with Special:ActiveUsers, let's skip
RC_EXTERNAL when doing the count.
Also, it turns out the "recenteditcount" property in the result is
really more like "recentactions" since it counts any action that shows
up in recentchanges; the discrepancy between that and "editcount" can be
confusing if someone is doing a lot of logged actions that don't create
dummy revisions. Let's rename that, but we'll have to keep the old
property around for a while for BC.
Bug: 64505
Bug: 64507
Bug: 67301
Change-Id: I461e92819188c311cbb3853bc6bfad45962c8d7b
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
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
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
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
Filter for an unused right gives an empty group array, which
is not added to the query and than all users (with limit) are
selected.
Change-Id: I57c3c4d2b49653d71391b0d7755fdc0ad1d3a7d0
This introduce the syntax from aliased table names for aliased field
names into the abstract database layer:
array( 'alias' => 'field' ) gives 'field AS alias'
This patch also includes changes to query pages, api and some more
places to show, how the new syntax looks in "production".
This allow us to remove the "AS" for Non-PostgreSQL databases, if we
want that.
Change-Id: I5f0de1c2f29092c173aec3de93ffdef436799e8d
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
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
Listings with aurights can't show users with rights which are
granted by implicit or auto-promoted groups like *, user, or autoconfirmed.
This is my first commit, btw.
Change-Id: I083eb977393729961317d0f3cf9f7cfaa50fde51
Add some calls to Database::timestamp
Change some calls from Database::strencode to
Database::addQuotes to avoid ' in raw sql
Remove ' from ints in raw sql
Rename some vars to avoid duplicate names
Change-Id: I63f5602fa968f969a42932902a3ccc45fc54b432
Follow up to: I7d115e734cb8c93dcf6dc3b98bdbc81975951273.
I have replaced $this->keyToTitle calls with simple str_replace.
As a result invalid user names will be accepted in parameters, so
the chain of requests based on query-continue will not be broken
by invalid entry in the database.
Change-Id: I8a80fe6395ae6e9304e4d9ec7b604195ec3c9d00
Some MediaWiki installations have invalid user names in user table
(most notable example: en.wikipedia). This commit DOES NOT resolve
the issue completely, it only makes the API behave more gracefully.
I have replaced User::newFromName call with User::newFromId, so the
User object should be always constructed. In case it was not, an
empty array will be provided instead of null when returning user
rights. I have removed keyToTitle calls for ContinueEnumParameter
as user names in the database are stored without underscores
(en.wikipedia has of course one user with _ in the database...).
This should fix invalidtitle error thrown.
There is one issue I don't know how to solve. When API outputs in
query-continue aufrom value with invalid user name, subsequent
call with aufrom set will return an error, because input parameters
'from' and 'to' are passed to keyToTitle method too. Should I
replace it with simple str_replace('_', ' ')?
Change-Id: I7d115e734cb8c93dcf6dc3b98bdbc81975951273
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.
