Page MenuHomePhabricator

Use ar_parent_id on undeletion
Closed, ResolvedPublic

Description

When a page is deleted, the revision.rev_parent_id field is saved as archive.ar_parent_id for all revisions when they are moved from revision into archive. But when a page is undeleted, each rev_parent_id is set to 0 regardless of the ar_parent_id value so there is loss of information.

There was T30553 about the problem but it seems that only half of it actually happened?!

Edit: Although I still don't see any code which would explicitly handle ar_parent_id when undeleting, it seems to be a problem of the API only, see the comment below.

Event Timeline

Actually, what used to happen is that the rev_parent_id was automatically determined based on comparison of the rev_id values, which usually produced a nonzero value. Now the problem seems to be partially solved, but see T185167 for adding something to the undelete interface to mimic the old behavior.

Huh, it seems that the Special:Undelete page sets rev_parent_id correctly somehow, but the API:Undelete module always sets it to 0.

Anomie assigned this task to Addshore.
Anomie subscribed.

I just tested this on the development master branch and the rev_parent_id was preserved correctly across undeletion both via the web UI and the action API. Further, since both the web UI and the action API perform the undeletion by calling PageArchive::undelete(), it seems unlikely that one would have different behavior than the other.

While I don't see any changes that would have fixed this between the currently-deployed 1.31.0-wmf.17 branch and the development master, the current development master is scheduled to be deployed to be deployed to WMF wikis with 1.31.0-wmf.20, see https://www.mediawiki.org/wiki/MediaWiki_1.31/Roadmap for the schedule.

My best guess is that this was fixed with rMW745823287498: [MCR] Use RevisionStore::getArchiveQueryInfo in PageArchive, which was deployed to WMF wikis with 1.31.0-wmf.16.

T185167: Add a "Reset parent IDs" checkbox to the undelete interface is indeed related, in that that bug is complaining about the fact that this bug was fixed.

Further, since both the web UI and the action API perform the undeletion by calling PageArchive::undelete(), it seems unlikely that one would have different behavior than the other.

Well, that's exactly what happens in MW 1.30.0... Let's hope you're right about the fix.