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
Old and very old log params may omit a duration or flags. Always adds
these parameters to the output.
Also simplify the infinity check (see also
I5eb68c1fb6029da8289276ecf7c81330575029ef) and check the return of
strtotime.
Bug: T92902
Follow-Up: I6846ce09322eb404c506b5a51780a44ce9279fe2
Change-Id: I9109a27f416b002e5c562a1454d8c373dcf98fb4
This allows for extensions to format their log entry parameters, and
keeps the code for formatting API log entry parameters in the same place
as for other formatting.
This also takes the opportunity to rearrange the output format slightly
to avoid conflicts like what's happening in T73020.
Bug: T35235
Bug: T73020
Bug: T91466
Change-Id: I6846ce09322eb404c506b5a51780a44ce9279fe2
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
The backward compatibility code from
Ic149960f797d05fd088fa014390d791e3ae08687 missed the word ofield= and
nfield= which are hard coded in the old logging system and was outputted
to the api client.
Bug: T94377
Change-Id: I6c21b2b4bc2042ca07d376418b895874503568d5
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
The new block log params does not known the message number 4 (which is
index 3), therefore LogFormatter::getMessageParameters adds empty index
to keep the sequence in strong order.
But the loop was starting at index 4, not 3, which skips the needed
empty index 3 for the order.
Due to the missing $4 the legacy log params returning index 3 and 4,
therefore move them one up to match the new numbers.
Also fixed undefined index warnings for api's list=logevents
Follow-Up: Ibc7fcaa5a952ff90d42a6477da4baa429f3de64b
Change-Id: Ie23be129ee2bd1d2bf753c3b5cba293d64b8e0e8
The actions delete/event and delete/revision was not using the new
LogEntry to create the log row, changed this.
All params gets a number to avoid too many changes in DeleteLogFormatter
to keep the old and new format working.
Needs extra code for api to keep the output format unchanged.
Change-Id: Ic149960f797d05fd088fa014390d791e3ae08687
This mostly reverts commit 89b793b9f7. It also
finishes removing of the "fld_action" field in ApiQueryLogEvents that
was begun in that commit.
Bug: T74222
Change-Id: I185e42d029905fd2781f3ccbbef0687f51234b0d
Also do not include revdeleted entries in search results when
filtering by action if user cannot view that info.
Bug: 72222
Change-Id: I359ce3c67b1a7c24b76a8bade62ce0c77ff5efb0
This allows use of gender on Special:Log
Old message is kept for use in irc,
a test is added to ensure a unchanged irc message.
Change-Id: I0557a0d2751540cf0d7967333ffd767b934011c6
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
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
