Changing the visibility of a log event should also change the visibility of the corresponding null revision. See bug 70239#c10 .
Version: 1.24rc
Severity: minor
Description
Description
Details
Details
- Reference
- bz70261
Event Timeline
Comment Actions
I'm not convinced that it should, and it's possible to create a few nasty cases where bad thins would happen if it tried.
Comment Actions
(In reply to Jackmcbarn from comment #1)
I'm not convinced that it should, and it's possible to create a few nasty
cases where bad thins would happen if it tried.
What would be some examples? By the way, isn't UNCONFIRMED supposed to mean "possibly INVALID" rather than "possibly should be WONTFIXed"?
Comment Actions
UNCONFIRMED is used to mean both (at least here).
The issue is that there's nothing in the database or elsewhere that ties a null revision to its log event. Imagine that you move a page, then later use Special:MergeHistory to move its revisions to a different page. If you then try to revdel the move, it won't know where the revision went.
Comment Actions
Also, only move and protection events generate null revisions, and those aren't often revdel'd.
Comment Actions
(In reply to Jackmcbarn from comment #3)
UNCONFIRMED is used to mean both (at least here).
The issue is that there's nothing in the database or elsewhere that ties a
null revision to its log event. Imagine that you move a page, then later use
Special:MergeHistory to move its revisions to a different page. If you then
try to revdel the move, it won't know where the revision went.
Yeah, that's bug 68936 ("log_params should contain the revision IDs of null revisions created by log events"). I happen to want that revision ID data for use by [[mw:Extension:MirrorTools]], but it would help with this bug too.