"As a Curator, I want to get a list of the edits to a page that have been reverted, so that... (I can understand what kind of vandalism has happened to the page?)."
GET /page/{title}/history?filter=reverted
Similar to the history interface defined at T231343, except only versions that have since been reverted. Here, "reverted" is best-efforts based on tags.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T229661 Core REST API in MediaWiki | |||
| Open | None | T234951 Extended history API | |||
| Open | None | T231355 Curator gets reverted edit history | |||
| Resolved | BPirkle | T231597 Implement GET History Filter | |||
| Resolved | • eprodromou | T231599 Compose New History Queries | |||
| Resolved | apaskulin | T233431 Document REST API reverted edit history filter | |||
| Resolved | • Clarakosi | T235564 Implement Integration Tests for Existing iOS Endpoints | |||
| Resolved | brennen | T236333 Install wikidiff2 into mediawiki-quibble-api-testing-vendor-mysql-php72-docker |
@BPirkle @Anomie I think we got this wrong. When I look at:
https://en.wikipedia.beta.wmflabs.org/w/rest.php/v1/page/Barack_Obama/history?filter=reverted
...I see revisions that reverted other revisions. I think "reverted" means "the revisions that got reverted" not "the ones that reverted them". Am I off here?
There's no way for us to easily find "the revisions that got reverted", as that's not recorded anywhere. If that's what's wanted, we'll need to push back on it.
So, I wrote up an algorithm for doing it the hard way. It's expense (requires getting the entire page history) but cache-friendly.
Well, now there is, it's the mw-reverted tag. At the same time according to REST API docs, the reverted filter Returns only revisions that revert an earlier edit, which means it returns reverts, not reverted edits. That is... a bit inconsistent with the semantics in other places in core. Maybe that parameter should be renamed to something like revert and a new, proper reverted param should be introduced?
BTW, @eprodromou, very nice work on the reverted edits graph, I wish I knew that when I started my GSoC project (T248775) that was exactly about that. Also, I'm seeing this REST API project inventing solutions to problems that are really with the internal mechanics of core, not with interfacing with it. Retrieving reverted edits should be (IMO) easily possible for all users, including those interacting with HTML and the classic API, so putting the logic deciding which edits are reverted or not here, in the interface layer seems... pick your own adjective, I really don't want to be rude. :) I'm just trying to point to a more general problem with this API.
P.S. Reverts and reverted edits docs are here: https://www.mediawiki.org/wiki/Manual:Reverts