AFComputedVariable::compute() caused fatal errors when trying to handle
non-text content, e.g. in Special:AbuseLog.
For now, we just stub out some variables for non-textual content. Extensions
can still provide values for these using the AbuseFilter-interceptVariable hook.
A real solution requires us to make the Content object available along with the
variable array, or at the very least log the base revision id of filtered changes.
Change-Id: I795549b733f2f418b471223786d206fd8925d8fc
The title in the context provided for an edit may be a special page
in some cases, e.g. when an extension uses a special page for creating
new content, and the final name of the content is not yet known
when the EditFilterMergedContent hook is called.
This change will allow special pages to be used in this context.
Change-Id: I5551bff69e3b617a437bd043fdc893dbdcd9f09f
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
This changes the AbuseFilter to use Status objects for internal
error handling. This allows for more flexibility in passing error
messages back from hooks and avoids double escaping.
Change-Id: I72e1a6dd7dee19f889fc13b60456e9bfebd5e22b
This makes AbuseFilter use EditFilterMergedContent if support for
the ContentHandler infrastructure is present. This means living
without some nice bits of context, because EditFilterMergedContent
doesn't provide an EditPage object.
This requires core change I99a19c93 to work correctly.
Change-Id: Ibb9d4c9a36b8a199213958b920902e8006c71fe8
If $wgDisableCounters is set, using the variable will result
in a syntax error for an undefined variable.
Change-Id: I136484356506c87ac0e2ede088787e854a0a2fa9
This patch allows the current AbuseFilter to work with 1.19, by only
using MWTimestamp if MediaWiki is version 1.20 or later.
Api still needs fixing, but this will get filters running.
Change-Id: I7c9eaf777d529ce15dfd85761784f9ad1443f2bf
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
The link should not be shown to users that don't have the right to use it,
like with the tools and import pages
Change-Id: Ie48e61a7de61ab095d621845466aea56b7445f5a
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
Added two hooks to the AbuseFilter, one that allows altering of the
variables created for a specific user and one for title specific
variables. This a much cleaner way to add title or user specific
variables than using the current general-purpose hooks.
Change-Id: I7374846346dd220b5d0633c11c134030f98bcf00
