Since MediaWiki 1.36, this method is provisioned to replace creating
new instances of the services object. If one is already created and
seen by the service locator, just use it.
Change-Id: I9509497a8380194aa93310343b1896521070fc31
Additionally it switches the query from DB_PRIMARY to DB_REPLICA.
I understand the idea with a quick revert, but I do not think
it can be that quick - to revert a newest revision of a page,
an editor or a bot needs to actually read it first, and reads
come from a replica. So we know at least some replicas already
had the latest revision showing to the user. Very likely by the
time revert is made, we'd have it in all replicas. If not - oh well,
we can't be perfect. But we shouldn't really do such a query on
primary - it's too heavy.
Change-Id: I2fae8dbe5f19635f4d99e26242e3b08ddad8f8af
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
JobRunner catches all exceptions and hides them in the status array,
meaning that it is not obvious when a job fails during a test case.
So, introduce MediaWikiIntegrationTestCase::runJobs(), which runs jobs
and asserts various things about the returned status array.
Depends-On: I4f4790c5d16a0767790eeff202e0be8fcdaeda93
Depends-On: I118f9e3f8950fd82d7b02baed6705b29fd6ab7d5
Change-Id: I63603aa158f77df4b40add096cb248f3b24979f4
As we convert the RevisionRecord to using Authority,
we no longer need Title instances, so we can convert
that to PageIdentity.
Ideally, we'd part away from using Title at all, but:
1. For foreign wikis PageIdentity has stronger validation,
so calling PageIdentity getId() on Title will break things.
There's still a lot of code depending on lax Title guarantees,
so we keep it.
2. A lot of code still depends on Title, so we try to pass it
through even if we don't nesessarily need to, to save cost
on recreating it later on.
Bug: T271458
Depends-On: I287400b967b467ea18bebbb579e881a785a19158
Change-Id: I63d9807264d7e2295afef51fc9d982447f92fcbd
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
The tag is added to reverted edits as described in T254074.
Functionality:
* Adding the mw-reverted tag to reverted edits (duh)
* Limiting the maximum depth of the update through a config variable
(mitigation #2 from T259014).
* Only applying the reverted tag after the edit has been somehow
approved. Only the patrol subsystem currently implements this, but
there's a hook that extensions can use (mitigation #4 from T259014, more
explanation in T259103).
* When performing the delayed update, it is checked whether the reverted
edit was reverted itself. If so, the update is ignored. This is
probably the only way to make the feature work due to the lack of an
explicit "disapproval" mechanism other than reverting.
* The update is also ignored if the revert is marked as deleted.
Technical design:
* The update code is in RevertedTagUpdate.php, which is a deferrable
update, but is not used as such. It's separated to allow for better DI,
testing and better code reusability in the future.
* The update is queued / ran using the Job subsystem. The relevant job
is in RevertedTagUpdateJob.php
* PageUpdater determines whether the edit is approved or not and passes
that to the DerivedPageDataUpdater.
* The BeforeRevertedTagUpdate hook lets extensions decide whether the
update should be ran right away or await approval.
* DerivedPageDataUpdater checks whether the edit is a revert and if so
either enqueues the job (if it's auto-approved) or caches the EditResult
for later use (if it needs approval).
* RevertedTagUpdateManager allows for easy re-enqueueing of the update
for extensions. Thus, it has a very minimal interface.
Other notes:
* The unit testing setup for RevertedTagUpdate is a bit complicated,
but it was the only way I could make this class testable while using
the static ChangeTags class.
Bug: T254074
Depends-On: I86d0e660f0acd51a7351396c5c82a400d3963b94
Change-Id: I70d5b29fec6b6058613f7ac2fb49f9fad9dc8da4
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
Based on the patch that introduces manual revert detection, this is
to create a software-defined change tag that will be applied to all
edits that restore a page to an exact previous state. This is also
for consistency with mw-undo and mw-rollback that will make a
"reverted" tag appear on reverted edits in the future.
Note about the REST API tests: in the next patch in this chain
I encountered even more issues with comparing returned changed tags
with expectations, so I decided it'd better if we just checked the
change tags applied manually in these tests. Otherwise we can run into
nasty race conditions, as the reverted tag is processed after sending
the response to client in the deferred update. It also makes the test
hard to maintain.
Bug: T256001
Change-Id: Ic367886f39faedcb823222b7d63bf4d5cb236ae9
The code for manual revert detection is ran when building the
EditResult and the edit was not marked as a revert yet. It's
based on a SELECT looking for recent edits that match the new
revision's SHA1. There is no index over rev_sha1 field, so we
limit the search to N most recent edits, in order not to cause a
full table scan.
I think this shouldn't break any extensions by setting the
originalRevisionId in situations that weren't expected, almost no
extension uses that anyway:
https://codesearch.wmflabs.org/search/?q=%5C%24originalRevId&i=nope&files=&repos=
Bug: T256001
Change-Id: I4e38b382391b42e252cb66584be1e174cdfe348c
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
