There is already one for the js field, but we can't reuse it since "one
by one" doesn't make any sense here.
Change-Id: Iaf01e19f4006b3d578bb2201cf9108fe46d56085
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
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
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
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
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
In If67035991a0835ec3edc13be4543e6b40c76c3ea I changed a couple of links
to OOUI buttons, but forgot to add one of these to the output (and to
enable OOUI as well).
Change-Id: I7dd4b554bae406bc0c8326867298302ee10b47f2
With I5e3764dbec8ac21f20c460181ae78ed73eca92f6 I introduced a function
to check that two blocks with different wordings refer to the same
duration. While that functions works good 99.9% of the time, there's a
highly unlikely but actual problem: if one of the operand is parsed at
time x and the other at time x+1 (in seconds, and this may happen even
if it gets parsed 1 ms later), the 2 durations will be considered
different and this may be annoying. With this patch I introduce another
tiny function which uses strtotime to parse a duration, but uses the
second parameter (=0) to avoid relativeness to the current time. Again,
this isn't likely to occurr, but since the fix is straightforward we'd
better do it. Also, now global durations aren't parsed at every
iteration (previously they were due to the same problem, amplified by
time distance between the first and the last iteration).
Change-Id: I11a078f298aaed9631d7f422c6b9b722d28e73cc
With If16975dd394cfdb3c57ff263366c2fc865de362a I broke flags checkboxes,
i.e. the one for enabling/deleting/etc. a filter. In fact, I
misunderstood the way cbReadOnlyAttribute was used (a dirty way,
actually) and this caused such checkboxes not to be disabled if the user
didn't have rights to edit the filter.
Change-Id: Ibf80b54e0f620734ad7767e4769a93bbf1feccff
The $deadActions array is populated but never used. At first I thought
it was about actions which aren't available, but this isn't right.
Instead, it's only used to keep track of available actions which aren't
used in the current filter. Which is some data that we don't need, nor
there's nothing we may do with that.
Bug: T188181
Change-Id: Ibdfeb92ccd790c0b1a4d79b382b053b9361459f8
We used to display the checkbox to block talk without checking if
it was defined. This caused a warning and an empty space with
wgBlockAllowsUTEdit set to false.
Change-Id: I97f82633e932de7e325615473c85245a406a55ef
Like we did for other links in /diff and /histories, there are some
links that we'd better display as OOUI buttons. Also, use the Html
class' specific method to show errorboxes.
Bug: T132284
Change-Id: If67035991a0835ec3edc13be4543e6b40c76c3ea
I'd like to have this reviewed by more than one user before merging, to avoid regressions of annoying typos.
Change-Id: I91a9c5cca55e540a6c95b750579c1c369a760b15
I found these vulnerabilities while trying to setup seccheck. Although
I'm not sure whether seccheck recognised them, I'm sure that they exist
since I did manual tests, and it's possible to inject custom scripts
with these.
Change-Id: I97804be8352a1b784d483195edb29e363a0c616e
This is taken from I6a57a28f22600aafb2e529587ecce6083e9f7da4 and makes
all the needed changes to make phan pass. Seccheck will instead fail,
but since it's not clear how to fix it (and it is non-voting), for the
moment we may merge this and enable phan on IC.
Bug: T192325
Change-Id: I77648b6f8e146114fd43bb0f4dfccdb36b7ac1ac
Follow-up of Iaeae672dca66ffc745054daabd6f0eae7dfbc648. Some actions
were still marked with red, specifically the ones with block inside. The
reason is that we stored the 'blocktalk' parameter as an emtpy string if
false, which wasn't filtered when loading request. Changing the empty
string to something different is enough to fix the problem, hopefully
without regressions. Note that this isn't retroactive and needs an edit
to become effective.
Bug: T189681
Change-Id: I7d7f0606fc23bad5ba342076066ab0e935680b3f
This should fix every error with excluded rules, leaving only the one
for $wgTitle. A double check would be nice in order to avoid regressions
due to stupid mistakes.
Bug: T178007
Change-Id: I22c179f3a01d652640304b59e43fcb5b5a9abac3
This is the long-term solution for the problem. The ToDo may be
unnecessary, but leaving it there as a caveat.
Bug: T190602
Change-Id: I5e3764dbec8ac21f20c460181ae78ed73eca92f6
Currently users can save filters without title or pattern. This
shouldn't be allowed since it leads to lack of clarity. The check is
only performed server-side, since when implementing Ace editor we won't
be able to (easily) add a pure HTML requirement for the pattern field.
Bug: T173947
Change-Id: I1a0418b87cdb1ff423238fcdf1c743930500e605
This is part of a project to enchance blocking in AF. With this patch,
users are allowed to specify two block durations for each filter, one
for anonymous and one for registered users. For backward compatibility,
default values are set to the global variables.
Bug: T32024
Change-Id: Ib072433d19dabae48d8514e08be9893135b5d63c
Currently, the message informing that some actions have been disabled is
quite impossible to notice at a first glance, since it's a bit confused
with other form elements. However it actually is a warning and needs to
be treated as that.
Change-Id: I0d851333f8da200fb0b9b0c7d05ccd1f63e9e948
Per T178092, AbuseFilter now maintains compatibility with older versions
of MediaWiki using release branches. Thus, various back-compat code
paths may be removed from the master branch.
Change-Id: Ia1b5eade30d7486e3b1b386b15a7db4e5c8cfead