Page MenuHomePhabricator

Suppressed edits should not appear in Special:DeletedContributions and Special:Undelete
Open, MediumPublicBUG REPORT

Description

Author: mike.lifeguard+bugs

Description:
I think this has been reported already.

When the page title is what we want to hide, there seems to be no way to do it with revision deletion - it still appears in Special:DeletedContributions regardless what revision deletion options you've used. There needs to be some way to hide the page title here.


Version: unspecified
Severity: major
URL: http://simple.wikipedia.org/w/index.php?limit=50&title=Special%3ADeletedContributions&target=149.254.56.32&namespace=
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37120

Details

Reference
bz19725

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:43 PM
bzimport set Reference to bz19725.
bzimport added a subscriber: Unknown Object (MLST).

mike.lifeguard+bugs wrote:

There's also no way to hide page titles on Special:Undelete: http://nl.wikipedia.org/w/index.php?title=Speciaal:Terugplaatsen&prefix=User%3ALKD

Yes, Special:Undelete still shows hidden pages and can't be hidden per oversight; Special:DeletedContributions instead can be oversighted so that sysops can't see the entry anymore (while stewards are able to see them): http://nl.wikipedia.org/w/index.php?title=Speciaal:VerwijderdeBijdragen&dir=prev&offset=20090722133809&limit=1&target=MrBlueSky (example); wpHideUser and wpHideRestricted have to be checked to do that

Kind regards
DerHexer

mike.lifeguard+bugs wrote:

Thinking aloud: If this is fixed, how will we track the edits after they've been nuked? This could make CheckUsers' jobs *a lot* harder, I think... maybe we want to allow these edits to show up for people who can unhide them, but not others. The use cases here need some more thought put into them.

koneko wrote:

So basically, what we want is something like
*a normal revision deletion can be seen in special:undelete by sysops
*an "oversight" (revision deletion + hidden from admins) should be seenable by those who can delete like that but not by regular sysops

am I right ?

I think this bug and bug 20290 are the same RFE.

Lowering priority since we've lived through a couple years of this misery.

Priority increases over time, not decreases.

Is this bug still present? I'm having trouble reproducing.

(In reply to comment #7)

Priority increases over time, not decreases.

Unfortunately, developers don't act like that.

(In reply to comment #9)

(In reply to comment #7)

Priority increases over time, not decreases.

Unfortunately, developers don't act like that.

Bug reports and RFEs are not developers. The lack of existing resources doesn't change the importance of bugs.

(In reply to comment #10)

Bug reports and RFEs are not developers. The lack of existing resources
doesn't change the importance of bugs.

You're right, they aren't developers.

Answering Bawolff's question in Comment 8 would help. He is having trouble reproducing it now. Is the problem still present?

Since r54027 suppressed usernames are not shown on Special:DeletedContributions/username for non-suppressrevision user.

Suppressed revision are shown on action=history and so it is right, when a sysop (or other user with the rights for Special:Undelete) can see that revision on Special:Undelete.

So the problem this bug reports is fixed, right?

(Note that the other issues raised in this bug may not be fixed, but this bug is not meant to be used as a placeholder for tracking related issues. We use tracking bugs for that purpose snd file related bugs as blockers for the tracking bug.)

Closing this since no one has been able to reproduce the problem and comment #12 suggests it is acting as it should.

Not fixed: On http://nl.wikipedia.org/w/index.php?title=Speciaal:Terugplaatsen&prefix=User%3ALKD you can still read “Gebruiker:LKD ist eine miese Sau!” what was suppressed/oversighted on http://nl.wikipedia.org/w/index.php?title=Speciaal:Terugplaatsen&target=Gebruiker%3ALKD+ist+eine+miese+Sau! and so shouldn't be visible for sysops on that special page. Same for oversighted pages on http://en.wikipedia.org/w/index.php?title=Special%3AUndelete&prefix=Nawlin and others.

To clarify, is this happening just in some intermittent cases, or is this true for all suppressed edits?

For all suppressed edits.

Example: I've created http://test.wikipedia.org/w/index.php?title=User:DerHexer/Test3, suppressed it entirely: http://test.wikipedia.org/wiki/Special:Undelete/User:DerHexer/Test3 and its name “User:DerHexer/Test3” is still visible for sysops on http://test.wikipedia.org/w/index.php?title=Special%3AUndelete&prefix=User%3ADerHexer (“User:DerHexer/Test3 (1 revision archived)”) [confirmed by local sysops without oversight rights].

yay a wiki where I have sysop rights so I can actually see this. :D

I think part of the problem was i misunderstood what was being reported.

Here is the situation as I understand it currently.

*You want to hide the fact a page ever existed under some title.
*You oversight it out of existence.
*However, if an admin looks at that page title, he will still see the '1 deleted revision'. If the user goes to the special:undelete of that page, the fact there was a revision is still listed, but all details of that revision are fully hidden.
*The fact the page at one point existed can also be gleaned by using the prefix option of special undelete.

*I can not reproduce the claim that such edits appear in deleted contribs as mentioned in comment 0. (possibly fixed in bug 17792 based on source code comments).

What should happen:
*totally suppressed revisions like that should not appear in a prefix search via special:undelete. This would stop people from finding such "hidden" pages
*Its also requested that the 'x deleted revisions' not be shown on the page, and the direct special:undelete view does not list those revisions.

The first point I think should happen. However for the second point, I could see not having 'x deleted revisions', but I think removing those revisions from the special:undelete view would complicate deletion history, and not all that good of an idea. (Especially when you mix suppressed and non-suppressed deleted revisions).

Created attachment 8516
Patch to make suppressed revisions not be counts when doing prefix search of special:undelete or on the '$1 deleted revisions' message when viewing a deleted page

Here's a patch that does the following.
*Makes the "x deleted edits" message at the top of a deleted page not count suppressed revisions.
*Makes suppressed revisions not show up when doing a prefix search of special:undelete. (It will count non-suppressed revisions only in the prefix search)

I used if the revision's text (content) is hidden from admins as the test for if to count in both the above cases. If you directly go to the undelete of that page, the suppressed revisions are still shown as they are now. (To do that would already require knowing what the page's title is, so it doesn't exactly reveal the secret title). If you have the suppressrevision right, then everything behaves like it does currently

Potential concerns with this patch (aka reasons I attached it to a bug instead of committing)

*Does it make sense to show different number of deleted revisions depending on if you have suppressrevision right, and have no indication that different numbers are shown to users without that right?
*Does it make sense to not count the revision only if the revision text is hidden from admins (at the end of the day the core of a deleted edit, is the text of that edit. OTOH, it might make sense to not count it only if the entire thing is suppressed, or perhaps if any part of it is suppressed. For comparison, special:deletedcontribs looks at the user field [but that makes sense since its per user]).

*Minor db concern. The query no longer uses a covering index. Does that matter? I don't think it does, but I'm not overly knowledgeable about these types of performance concerns.

Attached:

(In reply to comment #15)

Not fixed: On
http://nl.wikipedia.org/w/index.php?title=Speciaal:Terugplaatsen&prefix=User%3ALKD
you can still read “Gebruiker:LKD ist eine miese Sau!” what was
suppressed/oversighted on
http://nl.wikipedia.org/w/index.php?title=Speciaal:Terugplaatsen&target=Gebruiker%3ALKD+ist+eine+miese+Sau!
and so shouldn't be visible for sysops on that special page. Same for
oversighted pages on
http://en.wikipedia.org/w/index.php?title=Special%3AUndelete&prefix=Nawlin and
others.

In my opinion it is the principle of RevDelete, that you can see there is a revision, but you cannot see parts of it. That is for transparency. You cannot hide page titles with RevDelete.

The user [[nl:Gebruiker:LKD ist eine miese Sau!]] was renamed and not hidden.

(In reply to comment #18)

[…]

What should happen:

*totally suppressed revisions like that should not appear in a prefix search
via special:undelete. This would stop people from finding such "hidden" pages
*Its also requested that the 'x deleted revisions' not be shown on the page,
and the direct special:undelete view does not list those revisions.
[…]

For me the first one is more important. The second one could be left because of transparency issues: Sysop should be able to see that there was a revision but shouldn't see its text.

bug 20290 requests that there is human control over this.

There are times that even the timestamp have been deemed sensitive and been granted suppressed status (very rare, but very important)

fixed in r91561 (applied the patch from comment 19)

(In reply to comment #23)

fixed in r91561 (applied the patch from comment 19)

Reverted in r97297

Removing blocker status since this is the Friday before 1.18 deployment and this isn't really more than "nice to fix" category since the # of people affected is low.

sumanah wrote:

+need-review to signal to developers that this patch needs reviewing. Why was it reverted in r97297?

(In reply to comment #26)

+need-review to signal to developers that this patch needs reviewing. Why was
it reverted in r97297?

See discussion on r91561 - but basically because its unclear if the new behaviour makes sense.

quentinv57 wrote:

(Moved it back to major. This is not an enhancement but a real bug)

sumanah wrote:

Putting this on the Bug Wrangler's radar.

About the current patch:
"Basically this doesn't include an edit in the count if its text is hidden and its hidden from admins. (Not sure if it should not be included only if everything is hidden). Its also weird to show people different things depending if they have suppress rights, without really indicating that."

Any comments on that? Is this wanted? Or not?

As described, this appears to be the correct (desired) behaviour.

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 6 2022, 7:18 PM