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
In this change, a new passive user right named "viewsuppressed"
which can be used in order to view suppressed page content was added
to MediaWiki core.
Furthermore, this right was also added to the list of available rights,
to qqq.json and to en.json where also the description of the
"suppressrevision" right was adjusted in order to reflect reality.
Bug: 20476
Change-Id: Id1baacb9c782763db5e05ef8b5c1b761997efcc9
requireMaxOneParameter was added in
I53c4c6411e0b9e6383969afced0e4c193f1b64a1,
without update of the possible error list from that function call
Change-Id: I17f0ba8da4b21b2a5527bd4eff0d0e3308e24d9f
* Clone title so page_id is not 0 at log time.
* Change ApiQueryLogEvents to provide log_page as logpage (for all
rows, not just deletions) if ids are requested.
Bug: 26122
Change-Id: I1c7f3a84f10df05d6b37dccbad4c8232edf51580
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
API queries must be completely ordered for proper behavior; otherwise
you may get into a situation where a query returns the same continuation
value that was provided. Various modules that have been using timestamps
in/as their continuation parameter can easily run into this problem.
Normally we'd have to add additional fields to the relevant indexes to
be able to make this work without having filesorting queries (which
MySQL really doesn't do well, it fetches all matching rows and only
applies the limit after[1]). But InnoDB has a "feature" where it
effectively appends the table's primary key to all other indexes,[2]
which makes these queries be properly indexed in that situation.
Apparently we're ok with this, since Icc43b62f was merged depending on
this feature.
Also, this change fixes some MySQLisms and other oddities done to
ApiQueryRecentChanges in Icc43b62f.
[1]: https://dev.mysql.com/doc/refman/5.5/en/limit-optimization.html
[2]: https://dev.mysql.com/doc/refman/5.5/en/innodb-table-and-index.html
Bug: 24782
Change-Id: I4c9f8c0c2bfd831755d4fa20a18f93fef1effd28
The documentation of leaction= shows actions like "thanks/*", at the
moment this will result in a search for log_action='*', which is always
a empty list.
Changing the validation of param leaction to allow specific any string
for the asterisk in this wildcard action.
Change-Id: Ia77e499909ce6f25ce74617367fc5b622ea9a7c9
Per Sean Pringle:
> In all cases the STRAIGHT_JOIN forces an index scan on logging.times
> index, or more rarely a range access on logging.type_time index. Both
> query plans hit tens of millions of rows and take many minutes.
>
> Removing the STRAIGHT_JOIN allows the MariaDB query optimizer to
> choose a plan that takes seconds. Often it includes a filesort step,
> but more importantly it allows "index condition pushdown" which makes
> the filesort cheap.
Bug: 61889
Change-Id: Iad3905f29a2bdee1e3ebbfb2e1909b330faa8e81
* ApiQueryDeletedrevs, ApiQueryFilearchive, ApiQueryRecentChanges, and
ApiQueryWatchlist will now return entires where fields have been
revision-deleted. "Hidden" indicators will be provided as appropriate.
* ApiQueryImageInfo, ApiQueryLogEvents, ApiQueryRevisions,
ApiQueryContributions will now return field values in addition to the
"hidden" indicators when the requesting user has the necessary rights.
* Modules that return "hidden" indicators will now also return a
"suppressed" indicator.
* ApiQueryImageInfo will now return info for DELETED_FILE file revisions
if the requesting user has the 'deletedtext' right.
* ApiQueryLogEvents, when searching by user or title, will now return
entries where the user or action are revision-deleted if the
requesting user has the 'deletedhistory' right.
* ApiQueryContributions now uses the correct user rights rather than
'hideuser' to determine when to show contributions where the username
was revision-deleted.
* ApiQueryContributions will now indicate when the revision text is
hidden.
* Fix a bug in ApiQueryDeletedrevs found during testing where specifying
the "content" prop along with the "tags" prop or "drtag" parameter
would cause an SQL error.
* Fix various PHP warnings in ApiQueryFilearchive caused by the lack of
ArchivedFile::selectFields() fields.
* ApiQueryImageInfo::getInfo's $metadataOpts parameter has been renamed
$opts, and now may have an option to indicate the user to use for
RevDel visibility checks.
* ApiQueryWatchlist now properly uses the actual user's rights for
checking whether wlprop=patrol is allowed, rather than using the
wlowner's rights.
Bug: 27747
Bug: 27748
Bug: 28261
Bug: 34926
Bug: 48966
Change-Id: Idec2199976f460e1c73a26d0717e9fc4ab8042bb
DELETED_ACTION is supposed to hide the target of the log entry. But a
few places weren't doing this properly.
This fixes:
* API list=logevents no longer returns the pageid when the target is
hidden.
* Enhanced RecentChanges no longer includes the log target page in the
CSS class. This should also make the CSS class actually useful.
* Watchlist no longer shows log entries with DELETED_ACTION unless the
user has deletedhistory, and with SUPPRESSED_ACTION unless the user
has suppressrevision.
Bug: 58699
Change-Id: I57f13bfc970a33ffd5a399ffb450d9ed0b77902f
Update limitPerformer to search for IPs based on log_user_text, rather
than preventing any results from being returned. Also, make a
corresponding adjustment to list=logevents in the API, and remove
indexes to match the LogPager code.
Bug: 58691
Bug: 54404
Change-Id: Iae3f4ee5c7fba5b0b0f4f8fb3e67ac054c7b8dd7
Change I6b8f35bd removed the forcing of the change_tag_tag_id index in
the UI code paths, but didn't do the same for the API like it probably
should have.
Change-Id: Ie3a00b3a0ad194169a026370510f3e21c3abc079
Also fix warnings being shown and "anon" property being given to non-anon entries
when "userid" leprop was used but no "user".
Bug: 50315
Change-Id: I4df1c8c1040fb39d75ead5851d42b02d9de87a5a
I came across people complaining that it was hard to associate
upload log events to actual images since img_timestamp could
be different from log_timestamp, and generally no unique id.
Well I was there I made uploads use the new logging system.
Change-Id: Icd8662ecb9eb0f6c0ff9841bdbd5736d6dd0d015
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
Fixed ApiQueryLogEvents::addLogParams for unknown (probably extension)
log types which use the new log format (with keys like 4:foo:paramname).
Until now such keys we're directly put into the XML output resulting
in invalid XML (see bug 43221, which will be fixed by this). To prevent
this we just remove everything except the plain parameter name and use that
as key for the output.
Change-Id: I1a3c7ac624eb575b879d068d47d3a13c9972b1a1
Follow up Ie188bc6f: Necessary changes to api for rights log changes
Getting for new style logs:
Notice: Undefined offset: 1 in \includes\api\ApiQueryLogEvents.php on
line 245
Notice: Undefined offset: 0 in \includes\api\ApiQueryLogEvents.php on
line 245
Added a legacy part as seen by patrol and move for the rights log action
Change-Id: I1d0bdfb483dba30572e8dcf8faac331a77eb04c6
There was a recentchanges row on enwiki whose rc_params looked like
array('4::tags'=>array('db-g11')), and the tag name wasn't set
recursively so the inner array didn't get a tag name.
This still generates invalid XML of course, because <4::tags> isn't a
valid tag, but at least it doesn't fatal any more. RAWR XML GRUMBLE
Change-Id: Ibb775df4bd010bdce5632914f789230d8626c9e7
Doing this in steps of roughly 100 changes per commit, so that it remains
reviewable. This should be the one but last change set with the "easy"
ones for core.
Change-Id: If894a92dd65b2f5f4f096b9133685eb3b067a1d8
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
We still get legacy log entries, so grab the data from parameters as applicable
Should probably be encapsulated into DatabaseLogEntry itself, with a getParamValue esk wrapper
This fixes issues noticed on live site for the moment
TODO: Check if rights/block are still ok (probably not?)
TODO: If (especially if above needs doing) encapsulate grabbing of old/new parameters to logging code
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.
Since all those used ApiQueryBase::addWhereRange, added ApiQueryBase::addTimestampWhereRange, which does automagic timestamp conversion. Not tested whether this actually fixes problems in Postgres, but at least the API modules are still functional in SQLite
