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
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
Later, we will add a new POST request which will allow retrieving
the private details; it will have a mandatory "reason" parameter,
and will result in a log entry in the private details access log,
just like the web interface.
Bug: T210329
Change-Id: Iaca492371f48fecf543268c179a651841ed12c3f
Signed-off-by: sbassett <sbassett@wikimedia.org>
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
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
Now the required need will be abusefilter-modify OR
abusefilter-view-private for /tools, /test and /examine.
Bug: T193903
Change-Id: I3f1a91a2cc1df2272e5d4099cefd7c649a0683d5
I'd like to have this reviewed by more than one user before merging, to avoid regressions of annoying typos.
Change-Id: I91a9c5cca55e540a6c95b750579c1c369a760b15
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
Various selectFields() methods were deprecated in MediaWiki core change
Idcfd1556, replaced with getQueryInfo() methods.
Change-Id: If75d2e76c2f166bc40a544dd502da43171ce1e7b
Depends-On: Idcfd15568489d9f03a7ba4460e96610d33bc4089
After I544cdfa75c7472f2d98b2561bc6f6f9c2d2ad639 (dieWithError
and checkUserRightsAny), this is the oldest MediaWiki version
AbuseFilter can be run on.
AbortMove was removed from MediaWiki in 1.25, UploadVerifyFile
is only relevant for 1.27 and older.
(Replaces I1e962217c3b20d901a5742cf76339a3f488a6e97.)
Change-Id: Iec237b2887f72b115fdcef78d2d7a944ba82c784
