Having a single return statement inside a function isn't always the
best, but having 5 is probably worse. This patch changes three long
if-return/if-return/... to a single if/elseif + return.
Change-Id: I5f4603627c61cf1b93859fe6bcd952eac8e82359
We JOIN integer and text, so Postgres would always fail on these. As
mentioned in the task description, this is only a temporary solution
(although a clean and durable one), while the long-term one is
I7460a2d63f60c2933b36f8383a8abdbba8649e12.
Bug: T42757
Change-Id: Ifddd0bca1e8eaa7c70511fb0d0588457b4fd0669
The method is used to make afl_deleted = null treated as afl_deleted =
0. Digging into code history, I found that it's in place because:
*In rEABF14b850f891de27ea09a1439e3835f66c49ad773f the afl_deleted field
was introduced as NULL, and wasn't used.
*In rEABFfe39e38282fc4c7903eb3f8080dbf0bab0f697f4 it was ALTERed to be
"NOT NULL DEFAULT 0"
*And in rEABFa2ead8bfb5166e0b354f3bb3e09f39795cb5b1c0 this function was
introduced to "negate the need for a schema change".
However, when ALTERing afl_deleted to be NOT NULL DEFAULT 0, all NULL
values have been automatically converted to 0 thanks to the DEFAULT
clause, and being the column NOT NULL, of course no NULL are still
there... The ALTER was applied to all wikis (in 2010), so afl_deleted is
NOT NULL everywhere and we can safely treat it as such.
Change-Id: Iebd843629d26e392d2e24efc2795c767e854897a
Since double-equals are evil. I left some of them in place where I
wasn't sure, but I may be changed some which were intended to be
doubles. It could be a good idea to delay merging this patch until we'll
have more code coverage.
Change-Id: I1721a3ba532d481e3ecf35f51099c1438b6b73b2
Adding PHPdocs to every class members, in every file. This patch only
touches comments, and moved properties on their own lines. Note that
some of these properties would need to be moved, somehow changed, or
just removed (either because they're old, unused leftovers, or just
because we can move them to local scope), but I wanted to keep this
patch doc-only.
Change-Id: I9fe701445bea8f09d82783789ff1ec537ac6704b
As escaping is handled by makeExternalLink itself. This currently makes
seccheck fail for any patch and is a merge blocker.
Change-Id: I2d21632bbc59abd4ea48aebdb6572d53f8fc89cd
Following up I636b4e56f39282593c737ace1d6ff2d90900d997, enforce a basic
clientside validation and don't fill the field with the URL parameter if
it's not valid.
Change-Id: If4fd015dff64237375a0c4d3b9fbcefbd54dba3e
This adds the capability to filter AbuseLog using filter groups, if
there's at list an extra group (like flow). Since abuse_filter_log
doesn't store info about filter groups, this needs query on
abuse_filter, and its result must then be intersected with explicitly
searched filters, if any.
The way I wrote it takes several lines and IFs, but is meant to be less
subject to regression in case something gets moved.
Change-Id: I747ba491d2b390562ce5f71396eed095116d8eaf
In both SpecialAbuseLog and ApiQueryAbuseLog, we use
Title::getUserPermissionsErrors to check if the user is allowed to
perform 'abusefilter-log' on the API page... However, this is a
completely redundant check (which is also pretty expensive and queries
the master): for the SpecialPage, we can specify the required right in
the constructor and use checkPermissions, and for the API we can simply use checkUserRightsAny.
If I'm not mistaken, there's no benefit in using
getUserPermissionsErrors.
Change-Id: I4c4dbace67b24cc1f45e50ab1c0d251522935513
Instead of adding a message, do like core does by striking and greying
out the row. Plus, don't show the AbuseLog page description when hiding
entries, as it doesn't fit.
Change-Id: I645a89dd8df79d45ca440e0ba62adcdee921b8e9
This reverts commit 1ed75b4ae0.
Fixed the one which caused errors, by making articleFromTitle
only use WikiPage, instead of silently mixing WikiPage and Article.
Note for reviewers: this patch is identical to the one which was
previously +2ed, which was mostly correct. To see the actual change,
diff AFComputedVariable with 1..current.
Change-Id: I6747eaed861af6c40a3b1610aebcc1174296e9ed
Oversighted/deleted edits and log actions were entirely accessible to
non-oversighters via AbuseFilter/examine for RC, and via AbuseFilter/test.
Now, we take into account the revision/log visibility and user permissions to
determine what to show.
Other changes in this patch:
*Show the examine link if and only if the user can examine the given row
*If a revision is hidden but the user can see it, don't hide its elements in
ChangesList (only leave them striked/greyed)
*Make APIs better understand revision visibility.
*Make a clear distinction between deleted and suppressed edits/log
entries.
Co-authored with rxy <git@rxy.jp>
Bug: T207085
Change-Id: Icfa48e366a7e5e3abd5d2155ecfddfc09b378088
Fixed some comments adding explanations, fixing syntax, and parameter types
for docblocks. Also fixed some whitespace mess, and added a missing use
statement.
Change-Id: I3547c90bdaa2cab5443e8bf0c63b217fe6ba663f
Like we do in core for similar special pages. This is really helpful
when (un)hiding an entry.
Bug: T200645
Change-Id: I16450a2573e8987e31a83ec34f3dbb16fac94f81
Check if the entry is deleted first, since it's the strongest deletion
here (oversight level). Bonus: don't use implicit conversion when
checking the return value of SpecialAbuseLog::isHidden.
Bug: T200644
Change-Id: Ie5c4575ad29fe3dcb85a26cc74f1c59207df2852
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
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
They were defaulted to false with
I93ad51ffe7bee597d2d127f4c5d6b2929ffc8f7e, which broke use cases where
the page field is NOT required, nor has a 'required' => false explicitly
declared.
Bug: T194425
Change-Id: I5ab768c02a30b6d053104e590729ef22bb4e0808
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
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
Hopefully this is really the last one: the tiny form at the bottom of
Special:AbuseLog/# to access private details.
Bug: T132284
Change-Id: I3f91beb482b3b85e12b65464914b0ac57ec983df
Public comments are parsed in some places and they are
shown as plain text in others. Always show them as
plain text instead of parse them.
Bug: T173249
Bug: T141670
Change-Id: I173ffab1a99c1536cca260b76be0d95a4966b139
The IP is currently displayed as plain text. Add instead userLinks in
the usual way to provide some handy links for CUs.
Bug: T188600
Change-Id: I47ee007f450f06a1a19b4c7598373a952efbe06a
Users can choose whether they want to see entries
that changed the wiki or didn't (or they can apply
no filter).
Bug: T159061
Change-Id: I6cee9b001c26c4bbc837131781deef27d5e3ef1a
