Add an AbuseFilter log link to the subtitle of history pages.
Bug: T28934
Co-authored-by: Matěj Suchánek
Depends-On: I2e0e9e92d3fc303135b0eb9acf06b5fd120178a5
Depends-On: I58a3039b3755648bb0c8aaf87db48ace96ce9344
Change-Id: Ib89c48f2b8f3121ead184844844acee436e2fdd6
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionAnnotations.UnrecognizedAnnotation
* MediaWiki.Usage.InArrayUsage.Found
Change-Id: I46e414246c6597dd78b069f753d686c0d1c1c09d
A month ago SpecialBlock::getSuggestedDurations has been
modified, and now it also returns an "other" key. Since we don't need it
and it would break thing up, add a parameter to avoid dealing with that.
Depends-On: Ic2dbc961f7eebad11da53724b9cce2f804ffad39
Change-Id: Ica37ba7015a04445c2cbafebcc85726368e23cb0
This settles almost everything, leaving the tags part ready to be
further improved in the follow-ups.
Also, replaced some fields with totally different ones, improved the
warn preview area and improved a bit nojs experience by hiding unusable
buttons.
Bug: T132284
Bug: T154749
Change-Id: I7a5caa862a32f9792140c6a4d9708a2d20472672
This line first used to be just an "strlen". Then we merged
Iaeae672dca66ffc745054daabd6f0eae7dfbc648 to clean input and this caused
some "undefined index" notices. These were in turn fixed in Ibebedb566da705e77ffb831ebda6476adba07c93 by adding an "empty". However, this slightly changed the range of accepted parameters, for instance refusing 0 and '0'. Those should never be used, so this is just a theoretical problem, but we'd better be consistent and simplify this line.
Change-Id: I4643d0632acf5926ac8de5da9bcb3e5dc715fdc1
Otherwise, if the user is warned for e.g. trying to move a page, and
after the warning he tries to delete it, he won't be warned again. Since
filtered action (edit, move, delete...) can be really different, we
should repeat the warning if the action changed.
Bug: T199621
Change-Id: Ia481b2bf552e16de8485c246aa5612d5bb2cd6ca
The patch adds the logid parameter to the queryAbuseLog API, so that
users will be able to retrieve a single result with the given logid.
Bug: T36731
Change-Id: I9160c3690e86ea40560f6fa7721918965234c29e
The function used to determine if a row is hidden has three possible
return values: true, false and "implicit". While the first and the
second one refer to AF own suppressing system, 'implicit' means that the
revision associated with the log entry is deleted. However, we checked
for such return value with a boolean cast, which caused true and
'implicit' to be equally treated, thus hiding revdel'ed revisions to
sysops. Bonus: fixed a comment typo.
Bug: T191699
Change-Id: I87d3a6437bb966198175e4bfd063e30ed79c345f
We still had three entries of "LogPage", which is legacy and has some
problems (I7bb0e92b2906a2511fc4290bdc76fc39ec4617fe). This patch updates
two of them to ManualLogEntry. The last one is handled separately in
Ic23e724997e4748c8d0da8138aa73d31b17b7064.
Change-Id: I2a4f18ea6baebdc114078c57d8937ce4ca2aace5
I've been noticing this problem for a long time: sometimes, when the
filter editor stays open for a long time and you try to click "save filter",
the page is scrolled and the edit isn't save (while it is indeed saved
when clicking save again). I found out that this is due to edit token
not matching. If that happens and the request was posted, warn user to
re-save the edit.
Change-Id: Id0c5600bf22632f57d237a19b492cc9c297be736
To generate an OOUI-friendly array with dropdown values, we need to
rearrange the array we already get from AbuseFilter::getBuilderValues().
Right now we do it in a pretty dirty way, which also causes errors if
external values (e.g. Flow variables) are in the list. With this patch,
such conversion is simplified, explained in a comment, and doesn't
output errors anymore.
Change-Id: I1063865aeff2dfb637e95d7b2ff30da39ceeab67
This is something that hasn't been working since January 2009, when AF
didn't have arrays and all variables were computed non-lazily. In fact,
when reverting "degroup", we used to take old groups from edit vars, but
the variable may not have been computed for such edit. Plus, we treated
the var collection as an array instead of an AbuseFilterVariableHolder
object, and exploded user_groups since it was a string. With this patch
everything should start working as intended.
Change-Id: I76917b2e331291bd42daeef8d048507dc38048cb
The message 'abusefilter-edit-notallowed' is used twice and outputted
as plain text. This makes it really, really hard to notice. Wrap it in a
block-level errorbox to make sure users see it.
Change-Id: I6e5579f9a5e33f05520001e10ffdde928ffdcff0
Introduced in I75ce47d247cf6949117370c8c78ab7c6980538f3, the message name
was misspelled in the code and thus the message doesn't show.
Change-Id: Iad515c48035259340c4824d456a14010c977e7a8
Html::warningBox makes use of Html::rawElement, where as noted in docblock the given html must *not* be escaped. Plus, bold text was broken due to escaping.
This reverts commit 7dfe4bfcfd.
Change-Id: I505be036291d4c6ff33c0c4fed4dd83a5bb56c54
This fixes the following minor issues:
* In HistoryPager's getQueryInfo, afh_id was listed twice
* In AbuseFilter::translateFromHistory a field named "af_" was produced
if no actions were in use
* The topnav link "Recent filter changes" wasn't STRONGed on pages like
"Special:AbuseFilter/history/123"
* In checkAllFilters and AbuseFilter::getFilter, select from DB only the
fields that will be used.
* Simplify some inline comments and remove superfluous ones
Change-Id: If72b18bedac5e580487406e696aea1fd172ae45b
Right now it can manually be added when creating filters. Since the
distinction is interal to AbuseFilter, we can't use hooks to achieve the
goal (the tag isn't already usable from outside AF). Also making
isAllowedTag public to make it testable.
Change-Id: I75ce47d247cf6949117370c8c78ab7c6980538f3
Trying to write unit tests, there are some things in the code that make
it not well testable. Here, two of them are corrected:
1 - Use class constants instead of static variables inside a non-static
method. Otherwise such variables won't be reset between tests. The
change is made so that there'll be less impact on blame.
2 - Set af_enabled to true even in af_deleted is true as well. For three
reasons: the first is that we already perform validation for this, so no
need to secretly change the option to whatever we think would make
sense. Second, this redundant validation makes some tests fail. Third:
this way, if the user selects both enabled and deleted, when the warning
is shown he'll indeed see that both checkboxes are selected. Before, he
would only see wpFilterEnabled as selected.
Change-Id: Ib7a0335fa7fb3b8a21765438a720205656c1ea09
Actually, it seems like I almost got it right at the first try. I tested
every validation scenario and it worked as espected, so ready for
review.
Bug: T193596
Change-Id: I7fd1798030d83292ce46543e25c0c431ec345a28
All uses of "throw" inside AbuseFilterParser are now covered.
Bonus: added a standard suppresswarning when checking regex validity.
Change-Id: Iacb8f7a361079e3e117dc6845597c7bd8473e54a
doLevel- functions are currently documented in AFPToken. This patch
copies such comments on docblocks in AbuseFilterParser, the place where
this docs can really be helpful.
Change-Id: I4e47e760a56800faa9b0a1146e0d79f8955dca9a
Otherwise, a blank page will be considered as having a newline inside,
which won't be marked as added (or removed) in the diff. This requires
introducing a new method and leaving the old one for backward
compatibility, and may cause regressions.
Bug: T74329
Change-Id: I9a2397fd849544b499cad97a383e5331471e9d73
