Add missing parameters for abusefilter-edit-lastmod-text message on the
global filter list view. Two of the missing parameters are used by the
German translation of the message.
Bug: 51780
Change-Id: Iec5cf4f37f3d5f512c6c57de234e0f7b3a3ba502
This prevents an abuse filter admin from setting a custom warning
message (which are references to a non-translated, local wiki page),
for global filters (which can be on any wiki in any language).
bug: 45164
Change-Id: If61716053b75f45e4b70f78d3809ddd02ac6d83e
They still used old 1.18-style diffs, with styles copied from core.
Also:
* Remove the distinction between "simple" and "multiline" diff chunk,
enabling consistent styling
* Always show word-level diff, even in previously "simple" chunks
* Ensure the full context is always shown. This was clearly intended
(showing straight side-by-side comparison if there were no changes
and in "simple" chunks, diff otherwise; showing chunks with no
changes), but the default context is only 2 lines.
* Remove the distinction between 'wikitext' and 'text' diffs (all are
treated like 'text' was); it's impossible to show parsed code with
word-level diff, and it was only enabled for "simple" chunks, all of
which are intended to be one-line strings and are shown unparsed
elsewhere (e.g. filter description on the list on Special:AbuseFilter)
Bug: 36478
Change-Id: Ie24ad5ac5a9a2bc9b8f0fc0c4a03d5dfe7a6a83f
Right now the public description of AbuseFilters can contain
wikitext which will be parsed.
With this change the public description will be escaped
everywhere to prevent the parsing of eg. templates on
Special:AbuseFilter/history.
Change-Id: I777cac5fc195819ed296f791d0b8cc3ed2ae9eea
On top of that I changed /history to no longer show the
changes link if it's the first revision of the filter.
As I was on it I fixed the diff selection for diffs like
history/1/diff/2/next where change number 2 was compared
to the last change of the filter instead of the next one.
This probably went unnoticed because the /next action isn't
linked anywhere within the software itself.
Change-Id: Ic28bb696a4dbbb75e0bfcae1843ccefab1a9508a
The concept of different AbuseFilter groups had not properly been integrated, but should be now:
- The total number of matches is now group-specific
- .. Which will also fix the emergency shutdown calculations
- And a portion of incorrect code (involving $logged_local_filters) has been fixed (action != group)
Change-Id: I091199a9d74aee47dcb3d8942394a28e0ffd3234
Add a permission 'abusefilter-modify-global' which an administrator must
have to set global rules in the central database.
By default, this right is not associated with any group.
Change-Id: Ied92f7ffd90cb2d8eeb8f3f26b941edbb22b10d6
This patchset will make it possible for other extensions to tap into abusefilter with a custom group, and set different tresholds per group.
See https://gerrit.wikimedia.org/r/#/c/29569/
Change-Id: I21d31bdf28e26f3c830652efc08a247db9f7a86c
Passed the username parameter to all uses of abusefilter-diff-version.
Added documentation and dummy GENDER to the English message.
Change-Id: Ie4df30cd6bdc8a1451fe42478bdfba5acb05c8d7
I've been getting some errors on Special:AbuseFilter:
Warning: array_merge(): Argument #2 is not an array in /my/path/to/includes/Sanitizer.php on line 840
Warning: Invalid argument supplied for foreach() in /my/path/to/includes/Linker.php on line 366
This is the fix I came up with for them. I don't know how the previous code ever worked...
Change-Id: Ia6b159f184786d10fb696d267e65ce0530e8c64f
Resolved two wfMsg related FIXMEs introduced in
I02ba4ce31b6aca5b7324114093f8ece143abc295 using
foreach loops. (UNTESTED)
Change-Id: I84e9b875b670f9eaa9c8a70e85c3b1b637113033
* Replace deprecated methods.
* Remove no longer needed function fnmatch().
* Remove superfluous newlines.
* Remove unused and redundant local variables and globals.
* Deglobalization.
* Update documentation.
* Fix incorrect return values or add FIXMEs when in doubt.
* Escape output in a few places where needed.
* Remove unneeded MEDIAWIKI constant checks.
* Fix various JSHint/JSLint issues.
Patch Set 11: Merged https://gerrit.wikimedia.org/r/24701 into
this one per Siebrand's request
Change-Id: I02ba4ce31b6aca5b7324114093f8ece143abc295
Prevent attempting to revert a global rule's actions, when the action
happened on another wiki.
This is probably a temporary fix. Eventually, we may want to support
having a central administrator revert actions from global rules on
the local wikis.
Change-Id: Idd29596ddc21c37d81528a8ae6ed14367c373c5f
This message is used on the edit view when global filters are enabled to specify
whether or not a filter is global.
Patch Set 2: Add comments on where the message is used along with other messages
that can be formed by the concatenated string so they are easier to find
Change-Id: I5d1e99fa1dcaea8ed298affbd6388042f58686ee
* Update rules list view to show global rules toggle, global rules
* Update rule processing to get global rules from memcache, if no
rule exists, get them from the central database and store them in
memcache
* Delete global rule key whenever global rules are updated
* Add filtering for log by wiki on the central database, updated
table definitions to add index on afl_wiki
* Add global $wgAbuseFilterDisallowGlobalLocalBlocks so local wikis
can prevent global rules from locally blocking, removing or revoking
permissions.
* patchset 13: Include recommendations from Tim. Add db updates to
LoadExtensionSchemaUpdates hook.
* patchset 14: forgot to add new files
Change-Id: Id69a9d603f9679f838e8691c651a3e9d8461b422
Includes JS to sneakily change the default message if the user changes the filter group without having selected the "warn" action yet.
Change-Id: Ic753c3e018321dba3bf9f6d7bcee10a49c9faac8
The purpose of this change is to allow AFTv5 developers to run a separate list of filters against article feedback actions without issues of cross-contamination and bumping up against the condition limit.
Change-Id: I758795f01eaf3ff56c5720d660cd989ef95764a7
Fix Bug 24186 - "Examine" page is visible to users without abusefilter-log-detail right
Author: Nikola Kovacs
There was a more complex patch on Bug 24186, but I think he makes a
good argument why his is better.
Beware: I'm not set up to test AbuseFilter, but I didn't see anyone
else in core MW who regularly works on it.
* Implement accessors for isHardblock() and getRangeStart()/getRangeEnd() in the same fashion.
* Make the corresponding variables private, removing external accessors. This required updating AbuseFilter with non-B/C code, so I also implemented the rest of the changes I've made to the blocking backend in that extension.
* Move the "get an IP range which encompasses the given IP/range" logic to Block.php; will be needed later... :D
* Load abuse filter data from the master for edits, prevents unintended reversion in the case of replication lag.
* Load explicit field list, preventing another issue seen on Wikimedia and described in the comments.
