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
While trying to fix the fatal error reported in the task, I first tried
to bump equivset to a more recent version, and it seems to have fixed
it. I'm not sure whether this could lead to regressions, further
investigation coming.
Bug: T189560
Change-Id: I92bf98157a2b656a892e1d05deb4868c42e27fcd
Follow-up of Iacb8f7a361079e3e117dc6845597c7bd8473e54a for exceptions
thrown outside the parser. With this patch all uses of AFPUserVisibleException
will be covered.
Depends-On: Iacb8f7a361079e3e117dc6845597c7bd8473e54a
Change-Id: Ia7ef6eb832d5725a804a60cb58bc110b06c8abe2
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
The function was added with Ic916a6f8976e486d62d65156fa2dab56a55cf22a
but doesn't have messages for the dropdown.
Change-Id: Ibd7567a2b5277f6529e796a38871846abbfb4d54
Disabled vars can currently be overwritten by assigning them custom
values (e.g. old_text := 'foo'). However, this shouldn't be allowed to
avoid confusion.
Change-Id: I49136bf19371aee1e8068a9ae621310e1ab97c86
