These pages are read only pages so it's better to let users with
'abusefilter-view-private' to view history and diff of private filters
as 'abusefilter-modify' is a read+write right.
Bug: T126129
Change-Id: I9e15326c8d681000ab13ef8a50fa0eed4c24dbe6
$wgUser causes issues when it is not properly set when doing deletions in jobs and we want to
generate variables for the deletion performer anyway. WikiPage::doDeleteArticleReal already
ensures that $wgUser is only used when the performer is not set. Also updated docs.
Bug: T138571
Change-Id: If4895fe86acfd1dc2c439837df3830f9b2214336
The user's language should only be used when the exception is actually
displayed to the user.
This will also avoid "User::loadFromSession called before the end of
Setup.php" warnings when the syntax error is encountered during filter
execution for account autocreation, where we don't display it to the
user.
Bug: T124367
Change-Id: Ic17f56aecbe575ef15c6970c4298f889249e1904
The error code 'abusefilter-disallowed' or 'abusefilter-warning' is
used, depending on whether the filter only warns (and will allow the
action when retried) or prevents the user from performing the action.
The API response has been extended with some additional properties.
* For simple filters with no custom messages where the only action is
'disallow' or 'warn', the error code is the same as before.
* For filters with different actions, different error codes would
previously be returned; 'abusefilter-disallowed' will be returned
for them all, with the actions taken listed in the
.abusefilter.actions property of the API response.
* For filters with custom messages, the message key would previously
be used as the error code; now 'abusefilter-disallowed' or
'abusefilter-warning' is used, with the message available in the
.message property of the API response.
Also cleaned up some dead "forwards-compatibility" code and made a
recently introduced public method private.
The new functionality depends on Ifac8995a4d16d11840cee814177fc2808bc2072c
in MediaWiki core, older MediaWiki versions behave mostly as before.
The new .message property contains both the key and the parameters
duplicated from .abusefilter, so that the client doesn't have to know
what AbuseFilter is - it'll be able to just display the given
message with the given parameters. My specific use case is the upload
dialog in core (core shouldn't have to know about any extensions).
See also TitleBlacklist change I97c1f5c6bbbdfc0b8ea9914bb075d5299c14df8f.
Bug: T137961
Change-Id: I5780eae96930211191ecd874aacf53fdacb58f89
This allows filters using `action='upload'` to use the variables
`summary`, `new_wikitext` and several others that previously were only
provided when editing pages (`action='edit'`).
This is achieved using the new UploadVerifyUpload hook, introduced in
MediaWiki core in change Ie68801b307de8456e1753ba54a29c34c8063bc36.
`action='upload'` is now only used when publishing an upload, and not
for uploads to stash. A new `action='stashupload'` is introduced,
which is used for all uploads, including uploads to stash. This
behaves like `action='upload'` used to, and only provides file
metadata variables.
Filter authors should use `action='stashupload'` when a file can be
checked based only on the file contents, and `action='upload'` only
when the wikitext edit needs to be examined too.
Bug: T87381
Bug: T89252
Bug: T139848
Change-Id: I9654f82ecda82e4917fd0ac6b364b947a1434c73
* Make $filters act as a proper process cache with
lazy-loading and renamed it to $filterCache.
This avoids warnings that appeared in e91939fb3f.
* Make sure tags are applied on stash hits by storing
and reloading the static variable.
* Only check the cache for "edit" actions to avoid
filling the statsd and logging data with noise.
* Remove some unused class variables.
Bug: T138529
Change-Id: I8230fef0ad0db7ae63086470189204e319382cca
These variables are not used as "inputs" and are expensive to
compute (the main reason for caching to begin with).
Bug: T138550
Change-Id: I75849ca8eab941f75ebb82313d07d946bc095ae9
Edits should not wait on this to finish, especially since it does
both the minor and non-minor edit cases, only one of which actually
being useful. If the cache is there in time and there is no edit
summary it will be used; if not, there probably no reason to wait.
Bug: T138550
Change-Id: Ifc3b97ddf4dbb94f8ec3eacfcd5c8994c69aafbc
