Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
Ugh, my mistake.
Also added a test that should cover this. It fails on the previous
version of code, succeeds after applying this patch.
Bug: T262463
Change-Id: Ifda30daadea5a908505423caaf818b9f88f989ad
This is a follow-up of T259014 which describes issues stemming from
users being able to mark arbitrary edits as undos (mitigation #3).
A "dirty" undo is when the user clicks the undo link and applies some
changes to page's content before saving. By doing so, the user can
set the edit's content to anything, while still marking the edit
with the mw-undo change tag and communicating to extensions that this
was an undo.
With this patch EditPage will only consider edits that had their
content provided by automatic conflict resolution as undos. Anything
other than that can't be reliably considered an undo.
THIS CHANGES THE BEHAVIOR OF EditPage IN A NOTICEABLE MANNER.
Most users should not notice anything different. In my opinion this
change makes EditPage's behavior more sensible and is justified.
Bug: T259014
Change-Id: I9279230303a01461039ae8a4641d9897ce194f73
This is to fix issues with reverts being marked incorrectly,
especially when using the undoafter param which, until this patch,
wasn't really supported.
Honestly, EditPage is such a mess that I'm not sure if this is good
or not, but I did a lot of manual testing and it seems to work fine.
WikiPage::doEditContent() now checks whether the provided original
revision really has the same content as the new revision. This was
previously the task of callers, but that doesn't make much sense to
me because:
* This task would fall on EditPage otherwise and it should be more
focused on the UI side of things, without too much worrying about
backend details.
* This would require adding another parameter to WikiPage::
doEditContent(), $undoAfterId. It would be only useful for multiple-
revision undos that are not top revisions. In all other cases it
would be the same as $originalRevId.
* An extra sanity check before applying the value to the PageUpdater
won't hurt. Who knows what crazy ideas extensions might have.
The test cases are almost identical to those written for
McrUndoAction, so I decided to group them in a single file.
This should cover most undo cases.
Bug: T256915
Change-Id: I78641b3de0a012af932ea38265b695362f1f8491
