Adds a preference in the Watchlist section for watching uploaded files
for an account. Also works from API-based upload methods, so
UploadWizard and other tools should work fine.
Bug: T33313
Change-Id: If962e667de12b35904b2d1b2d9e99c26b588ec2a
Remove "\\" in namespacing. This is a Doxygen compatibility hack but
does not seem needed anymore, Doxygen reads namespaced class names
correctly, see e.g. https://doc.wikimedia.org/mediawiki-core/master/php/classMediaWiki_1_1Services_1_1ServiceContainer.html
PHP IDEs, on the other hand, were broken by the double backslash.
As an unrelated small doc fix, add parameter docs to PermissionError
constructor (parent has different arguments so the inherited
documentation is wrong).
Change-Id: I6da0f512b8c84f65fd20e90e4617108fe6a8fcd2
We use "IP address" consistently instead of "IP", but this was never
applied to the "range" addition.
Change-Id: I02fecf0b9e6a5b90f7a24209c7a1cdce64060b23
This lets us capture some basic endpoint timing data that is
lacking now, such as upload API call time.
Change-Id: If0627e2d78d82b22ed6bdaaa0fa7fe5f20ef50b1
This matches the behavior of Special:LinkSearch, and makes it more
likely to give sensible results for non-normalized input.
Bug: T130912
Change-Id: I2f60dd48fdfc24108110a24ad41b297ece7f33df
When MediaWiki encounters an unhandled exception, the error message it produces
includes a randomly-generated token, which allows the exception details to be
looked up in the error logs. This is useful but narrow: would it not be useful
to have the ability to retrieve all log records associated with a particular
request, rather than just exception details? (Hint: yes.)
So: introduce the notion of a request-global unique ID, retrievable via
WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id
(which provides the same facility) or some other software which sets a
UNIQUE_ID envvar, the value of that envvar is used as the request ID.
Otherwise, it is a randomly-generated 24-character string.
The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId()
is deprecated, accordingly. The request ID is also added as an annotation to
all Monolog-processed log records, and is exposed client-side as 'wgRequestId'.
This allows developers to associate a page view with log records even when the
page view does not result in an unhandled exception. (For the WMF, I also
intend to add it as an annotation to profiling data).
The request ID is not a tracking token; it does not persist, and it is
associated with a backend request, not with a particular user or a particular
session. Like the data in the NewPP report, the request ID is designed to be
cacheable, so that if, for example, a developer notices something weird in the
HTML, s/he can associate the output with a backend request regardless of
whether the response was served from the cache or directly from the backend.
Some prior art:
* https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html
* http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
* https://github.com/dabapps/django-log-request-id
* https://packagist.org/packages/php-middleware/request-id
* https://github.com/rhyselsmore/flask-request-id
Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
Adds a method for getting watchlist's notification timestamps
for a batch of LinkTargets.
Bug: T129482
Change-Id: I1f84212e7879a84b34bb3b53859069fcea282bba
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
Half of the work needed for handling this logging stream was done using
the channel name "ApiRequest" and the other half was done under the name
"ApiAction". The ApiRequest naming is easier to change at this point.
Bug: T108618
Change-Id: I5797731abeba22ef6ced7c8407ee670344d35b3d
This is for batch counting of visiting watchers, following the change
made in I2868c31fc09121de381d822e8f49194e3022bb42.
Query/logic has been extracted from ApiQueryInfo.
Bug: T129482
Change-Id: Ia9a534f5edb7af3cb7bf86be358dddb5d8c259cf
Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4 part of them problem
with incorrect API response but if when no watchers data is
fetched (ie. due to early return in ApiQueryInfo::getWatcherInfo),
response contains "watchers": null instead of skipping "watchers"
key entirely.
Bug: T129482
Change-Id: I9cab120ec4e6a9cf4626678e45ef14ea8efc8cbc
