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
* 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
This should improve page save times when manual edit summaries are
not used (and in a few cases, where they are).
Also fix a few annoying IDEA errors with block comments.
Bug: T137698
Depends-On: I2e407a3ac8b74e77bf88b1e34c1519f4dea63b80
Change-Id: I972e9147a5e52a941f478eaf1e96dc3ef8bdfe94
Repeats I61e4327ef3c7a31b19feef727de7d683f69e260b (which had to be
reverted due to a problem with an ancestor patch) without any
significant change.
Bug: T110448
Bug: T135360
Change-Id: I1688cf9fbcb04bb56d075c9f0876bd0ffeced4f6
Rename $wgAbuseFilterAvailableActions / $wgAbuseFilterRestrictedActions
to $wgAbuseFilterActions / $wgAbuseFilterRestrictions and make
them an associative array instead of a plain one, as that works more
sanely with extension registration. (The renaming helps to give more
useful errors to sites using the old config.)
Change-Id: I790d39c2849922d7daf7479f298cd90cf30af129
* Defer the slow profiling updates to post-send
* Convert to the object stash, so that all DCs see
the same values
Change-Id: I08316c6a3192bd69248cf5ab5a3ed8185341c313
$params[0] is the full prefixed page title, with namespace.
$params[1] is whether the move was with or without a redirect.
Bug: T121963
Change-Id: I880bb227f2fc97394a68187e7b8391acf5aeaf5e
We were only recording the total number of conditions used by all filters,
then treating it as if it was the per-filter number, resulting in crazy
stupid values. We were also not clearing this when a filter was edited.
(This does not fix the remaining problems mentioned on the task.)
Bug: T53294
Change-Id: I4f9f88f94469b977fe60c554b76e94edacac3462
Follow-up to b60829a60c.
I'll fix up message translations on Translatewiki when this is merged.
Bug: T132189
Change-Id: I1ecaedd7489b264ed621309b6fbfb63b9287a437
This reverts commit afb78deb84.
I'll guard this behind a global and fix up the localisation messages
in a separate commit. This is a straight revert.
Bug: T132189
Change-Id: Iff4aa6d7d543db8f47c5f81f3c206dafcd5373dc
* file_mime
The MIME type of the file, e.g. 'image/png'.
* file_mediatype
The media type of the file, one of 'UNKNOWN', 'BITMAP', 'DRAWING',
'AUDIO', 'VIDEO', 'MULTIMEDIA', 'OFFICE', 'TEXT', 'EXECUTABLE', 'ARCHIVE'.
* file_width
Width of the image in pixels, or 0 if it's inapplicable (e.g. for
audio files).
* file_height
Height of the image in pixels, or 0 if it's inapplicable (e.g. for
audio files).
* file_bits_per_channel
Bits per color channel of the image, or 0 if it's inapplicable (e.g.
for audio files). The most common value is 8.
Bug: T131643
Change-Id: Id355515a18d3674393332c0f4094e34f9f522623
Also
* Fix a bug where action-reverts doesn't work for anons
since the userid is always 0 for them, instead use the username.
* Start adding block log flags consistently with core
Bug: T124789
Change-Id: Ic6680dad891e2169b392fcfefc1e313af85bc92f
It'll be logging info for an anonymous user anyway, this just makes it
explicit.
Bug: T124367
Change-Id: I3c221d9af26b57b83e1be4db1698ca99fed9093c
Depends-On: I0b018a623fc833ca95d249ee21667a8f5690d50e
This was just set the present time anyway and this
code is called from EditFilterMergedContent, before
the edit in question was saved either.
Bug: T116557
Change-Id: I2f84cff0ad4f65b6c2572a89a267cf42d4a96f94
* This is very slow as there can easily be hundreds of filters,
each doing 6 memcached queries. Xenon flamegraphs show a lot
of time spent in this method, slowing down editing.
Change-Id: I31e4502bbd45cc284db3cd89eb34ad365c59905b
* Also removed some code duplication
* Use getConnectionRef in checkAllFilters so that the
DB connection can be reused
Bug: T93141
Change-Id: I17c5a976b6c45029cde4ed34ad82d69e365ae8c5
When importing filters, the code is using the magic value
of 'new' for the af_id field, which is of type bigint, to
indicate a not-yet-inserted record.
In MySQL, comparing a bigint to 'new' is legal but always false,
while in PostgreSQL it is illegal, and led to errors when checking
if the filter is hidden.
Fix this by adding special-case code to filterHidden so that it
always returns false for 'new' records. In PostgreSQL this fixes
the error, and in MySQL it avoids a pointless trip to the database.
Should be back patched to 1.23 and 1.24
Bug: T89514
Change-Id: Ib4b5585ac9889a1760ec930c555e7809a424538e
