This change s adds 'revert' as a separate log action for file reverts, as it
allows special formatting of log entries and revisions in UI and filtering
for file reverts specifically.
Even though there are no log entries with this log action right now, it does
seem that this was intended as some point, as there are corresponding
test cases in UploadLogFormatterTest, and is listed in
$wgLogActionsHandlers and https://www.mediawiki.org/wiki/API:Logevents
as well. Furthermore, the i18n message 'logentry-upload-revert' already
existed before this change.
Because this functionality can not be provided by tags, the 'mw-undo' tag
is not suited for this use case. However, it could be added additionally to
all log entries with this log action..
Bug: T60209
Change-Id: Ie1ccd8053dc5de58b2297a8460219f0233aab968
The documentation already claimed it returned array,
this is now actually true. Follows-up 037c06e886.
There are two ways it could be null:
* The setTags() method was never called, and the class member
was implicitly null by default.
* The setTags() method was called with $tags = null.
This happens WikiPage::doUpdateRestrictions() among other places.
That could probably be fixed, but is out of scope for this change.
The getTags() method of this clss appears to have no outside
callers in MediaWiki core, nor in any other project indexed
by Codesearch.
Change-Id: Ib89c79ef90870506187c3c3b61464c2aa788c594
Currently, there are 3 block messages: sitewide, partial with restrictions, and
non-editing partial blocks. This will add namespace restrictions to the
partial editing blocks message type.
Bug: T204985
Change-Id: Ic17d5459e67c267fdee1fb2513d67428148ac85d
$logId holds the log entry ID of some specific log and the datatype
is an integer (int) which is correct but looking at the constructor,
it does take a bool (false) which contradicts the docs above. So per
@Thiemo's advice after review of prev PS, it would be better to replace
false with 0 and leave the docs untouched.
Change-Id: Ieceb79a6cbaa248e1b7a7d3c1d51eb26bb3a2d84
I'm intentionally only touching these protected properties and nothing
else, because I believe these are uncontroversial. They should be protected
according to modern SOLID standards, and actually are declared as
protected in the base class. What this patch effectively does is documenting
this fact, but it does not change anything.
Change-Id: I625307b58bd419c4a72e9842b2b46c08ed9b4f8e
It is an invalid value that should be (by spec) ignored by the
browser, but apparently some browsers don't ignore it, and when they
submit it back, it is converted to -0001-11-30 by our date parsing.
Bug: T209490
Change-Id: I2643767a0091c1c9db78706358903e1dc97b59d1
Block information needs to be more detailed if a block is not
sitewide. With this change, page restrictions will be visible
as part of the block information in Special:Contributions,
Special:Block, and Special:Log and via API
Bug: T197108
Change-Id: I5d2ef606f709bdd60bf52e2a048890b0f6360fca
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
When the date is specified using &year=...&month=... URL parameters
rather than &wpdate=..., HTMLForm can't automatically fill it in,
but we can explicitly specify the default.
Bug: T199856
Change-Id: I71f4953d57a3893190778e5bd763db108dc433d3
Also, the $default value in LogEventsList#getFiltersDesc was not
being generated properly and would have always been an empty array.
Bug: T199856
Change-Id: Id286c76259406521f12cda67a4a715032e022637
Now that all our supported PHP versions have array_filter()
with a third parameter, these functions aren't needed anymore.
Depends-On: I3b097a1a048baabcaca15dc214a3a1bb06e746cc
Depends-On: I0187e27ac47cbab099249572201d1a649226a734
Change-Id: I7cabd0252691a083cb749cf9d3a7a23f1d076c39
HTMLForm gets the input value from the request. The values
specified in the form descriptor were never used. (You can specify a
default value, but that uses the 'default' key anyway.)
Change-Id: I27934e1118492371e547dd5e94feb172a0510cc9
I missed this during conversion.
Follows-up on Iba3c6aa5ac40dcdee0792c2d045b238b02d76521.
Bug: T199856
Change-Id: If3f228425b217c9ccdb7d32e0bc899647797ed70
* All Xml generation code has been removed.
* The LogEventsListGetExtraInputs hook now needs a form
descriptor array and not plain HTML.
See I37e0d3e81a46239750465b9299279fbbd7c7f87a.
* LogPager and LogEventList also take the $day parameter
for 'From date (and earlier)' and pass it to getDateCond
as well.
* Since FormOptions can't automatically extract the date
from the request this is being done manually in the
execute method of Special:Log using MWTimestamp.
Bug: T117737
Change-Id: Iba3c6aa5ac40dcdee0792c2d045b238b02d76521
Whether or not LogFormatter::getActionText() and friends are safe
for html depends on the runtime value of LogFormatter::$plaintext
which is beyond the abilities of phan-taint-check's static analysis
to determine. Thus this method results in a lot of false positives.
To prevent that, add an annotation that marks the method as always
safe for html. This is not ideal, but refactoring this method while
maintaining back-compat looks like it would be very challenging.
Bug: T197002
Change-Id: I9aded350ed4acc733b4fb697dd3400686a178fa9
The number provided by the query can be arbitrary, so let's narrow the
input validation to booleans.
Bug: T194616
Change-Id: If03e6e2d5bbcf4f2d85047cc23ee5388b39fe114
