This message said "Actions taken when matched".
This is a perfect tense, which is confusing in context,
because it is the heading of the list of actions
that _will_ be taken when matched and not _have_ been taken.
Changing this to "Actions to take when matched".
Change-Id: I2adc5a23b3e9e087dec4986747a3cd5263608f0a
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
