Enable RevisionDelete on WMF wikis for admins
Closed, ResolvedPublic

Description

The lower level of RevisionDelete should be enabled for administrators when all issues are worked out. RevisionDelete has already been enabled for oversighters (cf. bug 15644), but admins still cannot do things like obfuscate a single revision.

Filed in "Site requests," but I didn't add the shell keyword as I'm not sure what still needs to be done to resolve this bug.


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz18780.
MZMcBride created this task.Via LegacyMay 13 2009, 2:25 AM
brion added a comment.Via ConduitMay 14 2009, 11:40 PM

Do we actually want to do this? The use case for removing individual old versions should be pretty rare, which is why we've got it in a tiny subgroup.

MZMcBride added a comment.Via ConduitMay 15 2009, 12:06 AM

Well, this feature is intended to replace the God-awful "delete the whole page and restore certain revisions" hack. Whether or not there are few enough requests to keep this feature in the hands of only oversighters is unclear. Surely someone will come along soon to offer their opinion. ;-)

bzimport added a comment.Via ConduitJun 3 2009, 11:26 PM

mike.lifeguard+bugs wrote:

(In reply to comment #1)

Do we actually want to do this? The use case for removing individual old
versions should be pretty rare, which is why we've got it in a tiny subgroup.

Yes. Wasn't that always the intention?

(In reply to comment #2)

Well, this feature is intended to replace the God-awful "delete the whole page
and restore certain revisions" hack. Whether or not there are few enough
requests to keep this feature in the hands of only oversighters is unclear.
Surely someone will come along soon to offer their opinion. ;-)

Most wikis don't have oversighters, and getting stewards to do it is really not
such a great idea - either we'd be swamped, or people would just continue to
use the "God-awful hack" (the latter being both more likely and worse). Even for wikis with oversighters, I doubt we want to lay this on them - mostly due to workload, but also because it's not what they were elected/appointed to do.

bzimport added a comment.Via ConduitJun 3 2009, 11:31 PM

chrisipk wrote:

(In reply to comment #3)

(In reply to comment #1)
> Do we actually want to do this? The use case for removing individual old
> versions should be pretty rare, which is why we've got it in a tiny subgroup.
>

Yes. Wasn't that always the intention?

I also had the impression that enabling this for sysops was on the agenda all along. There are many reasons to hide revisions from the greater public but still leave them accessible for admins. Not all to-be-deleted content is deleted for privacy reasons (which is mainly what oversight is for). Think about copyright violations, for example. Those need to be removed but also need to be accessible for restoration, should we receive OTRS permission.

IAlex added a comment.Via ConduitJul 27 2009, 6:32 PM
  • Bug 19697 has been marked as a duplicate of this bug. ***
IAlex added a comment.Via ConduitJul 27 2009, 6:33 PM
  • Bug 19819 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitAug 5 2009, 3:31 AM

mike.lifeguard+bugs wrote:

Please note this keeps coming up repeatedly, and repeatedly people seem very confused that this hasn't been done. What will it take to have this enabled?

bzimport added a comment.Via ConduitAug 10 2009, 11:10 PM

mike.lifeguard+bugs wrote:

(In reply to comment #7)

Please note this keeps coming up repeatedly, and repeatedly people seem very
confused that this hasn't been done. What will it take to have this enabled?

Brion wanted to be sure there were no open bugs that would block this from being done. FTR, I did look through open revision deletion bugs and although there is still work to do, I didn't see anything that'd block this from being done. The relevant ones are:
*bug 18335 (which probably deserves a once-over from Brion, he may consider it a blocker)
*bug 17806
*bug 18862

brion added a comment.Via ConduitAug 10 2009, 11:27 PM

Assigning this to me to double-check anything else we need to do before setting
it up...

MZMcBride added a comment.Via ConduitAug 11 2009, 6:27 AM
  • bug 19199 --> could change the entire configuration, if implemented.
  • bug 17881 --> if admins start doing suppression frequently, end users will want to Special:Log/suppress to be a bit more intuitive.
  • bug 15814 --> tagged with schema-change; unclear whether this was / needs to be applied to WMF wikis.
bzimport added a comment.Via ConduitNov 23 2009, 7:23 AM

foxyloxy.wikimedia wrote:

It should be noted that the enwiki community has reached consensus on the feature being enabled for administrators and has approved a policy for its use. bug 21165 requests that the feature be enabled.

bzimport added a comment.Via ConduitDec 1 2009, 8:02 AM

FT2.wiki wrote:

Having worked with RevisionDelete intensely (producing stats for its usage, interface work, bug hunting, oversighter), my main concern is the effect of bug 21279. Log, revision and action links break all over the place in a non-intuitive and non-easy-fixable manner, because revisions can move between "normal" and "deleted" -- and the two use entirely different (incompatible) schemas and link notation.

Revisions are identified via &oldid=.. on wiki, but via Special:Undelete + timestamp (!) if deleted.

Revisiondeleted items are identified by revisionid and the parameter "&revision" in the link on wiki, but "&archive" if deleted.

So a revision that is deleted or undeleted (as opposed to RevDelete visibility changed) causes any and all links to the revision, to any diffs involving the revision, and to any delete log entries concerning revDelete actions about the revision, to break.

Worse: even given a (deleted or normal) revision, a (deleted or normal) diff or a log entry reference, identifying the item concerned can be very difficult or impossible, other than by undeleting all and hoping the link works again, then re-deleting.

Having seen this close up, this one's a "breaker" for me: Admins need to be able to use those logs as a tool to review others' actions. I couldn't advocate giving RevDelete to a few thousand admins across multiple wikis, until this is resolved and links relied on by admins for scrutiny, review and understanding, won't fail without a clue following every delete/undelete action.

Several possible fixes are discussed in bug 21279 and include a "revision is deleted" bit (bug 21279 comment #2, Happy-melon, also allows withdrawal of oversight in full), once-off schema change so that all revisions whether deleted or not use the same revisionID to identify them plus a conversion table for old timestamp links to revisionID so existing links still work (bug 18104), or creation of a RevisionMove tool so that selective undelete can be withdrawn (bug 21312).

bzimport added a comment.Via ConduitDec 1 2009, 9:33 PM

jake wrote:

I don't think this should be a blocker. For revdeleted diffs, a link to the diff shows a link to view its contents to those with permission to do so. That seems to be a good enough permanent link to me. What is more, transparency actually gets a whole lot better, because, as you say, a link to a diff deleted with selective deletion as is the practice now will completely break.

bzimport added a comment.Via ConduitDec 1 2009, 10:35 PM

FT2.wiki wrote:

That's exactly the problem. It actually doesn't.

"For revdeleted diffs, a link to the diff shows a link to view its contents... a good enough permanent link"

The problem is, if the revision is at any time later, deleted or undeleted, the log link breaks. It doesn't even just slightly break - it breaks completely. It becomes extremely difficult to see what revisions were being referred to.

As someone who has spent most of 2009 trying to get RevisionDelete ready to use, bug hunting, interface cleanup, and the like, I would dearly love to see it in use by administrators on the projects that wish it enabled. But I've already hit more than a few times, trying to work out what went on in a dispute or article history, where it's almost impossible because the links to the diffs in the logs are effectively junk links. The log entry becomes completely unusable. There's a note that admin X did Y for some reason, and no way to click through or find what revisions they did it on, and no way to see the underlying material. Sometimes theer are few deleted revisions and it's easy. Not all the time. If that's being hit often enough to impede admin work, when RevDelete is only used by oversighters, then it's going to happen more frequently if opened up to 1700 admins. An issue that kills log links this way, is likely to be a blocker by any definition.

bzimport added a comment.Via ConduitDec 1 2009, 10:46 PM

jake wrote:

I get it now. That is quite a problem.

bzimport added a comment.Via ConduitDec 9 2009, 5:30 PM

biblical_character wrote:

For smaller wikis, abandoning delete almost altogether and moving it to an admin-only "Deleted:" namespace then deleting the resulting redirect may be a solution. I don't see this as viable on en-wiki.

[Very] long-term, introducing a "delete+revdelete 2.0" which is rewritten from scratch may be the way to go. However, this would be a major undertaking and likely wouldn't be worth the effort if there is any easier, even partial solution, that allows the wikis to do what they want to do.

DerHexer added a comment.Via ConduitDec 11 2009, 5:18 PM

(In reply to comment #14)

That's exactly the problem. It actually doesn't.

"For revdeleted diffs, a link to the diff shows a link to view its contents...
a good enough permanent link"

The problem is, if the revision is at any time later, deleted or undeleted, the
log link breaks. It doesn't even just slightly break - it breaks completely. It
becomes extremely difficult to see what revisions were being referred to.

If you'd restore the previous state (deleted resp. undeleted) [e.g. by deleting or restoring all revision] the log link will not break anylonger. But that's not a solution.

bzimport added a comment.Via ConduitApr 26 2010, 7:03 AM

mike.lifeguard+bugs wrote:

Is Aaron still tasked with revision deletion stuff? Has anyone made a decision about the blockers yet?

Xeno added a comment.Via ConduitApr 26 2010, 7:45 PM

Please enable this.

The ability for administrators to quickly and efficiently remove sensitive or dangerous content without having to email oversight or use a wonky delete/restore selected revisions should trump the concern of not being able to link efficiently to the log action.

DerHexer added a comment.Via ConduitApr 26 2010, 8:28 PM

(In reply to comment #19)

Please enable this.

The ability for administrators to quickly and efficiently remove sensitive or
dangerous content without having to email oversight or use a wonky
delete/restore selected revisions should trump the concern of not being able to
link efficiently to the log action.

That's just one opinion. I prefer transparency and reversibility instead of quickness or efficiency.

Krinkle added a comment.Via ConduitMay 18 2010, 2:06 PM

This one seems to be enabled now.

http://noc.wikimedia.org/conf/InitialiseSettings.php.txt

'groupOverrides2' => array(

'default' => array(
    'sysop' => array(
        'deleterevision' => true,

See also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=21165#c12

Closing ticket

bzimport added a comment.Via ConduitMay 19 2010, 12:48 AM

FT2.wiki wrote:

Following discussion Werdna is considering this one along witht he others involved. Reopening until the decision is finalized.

bzimport added a comment.Via ConduitMay 19 2010, 2:14 AM

bugs wrote:

(In reply to comment #22)

Following discussion Werdna is considering this one along witht he others
involved. Reopening until the decision is finalized.

Hmmm? It's enabled still, so the bug is fixed. If someone disables it, *then* reopen the bug.

bzimport added a comment.Via ConduitMar 17 2011, 1:15 PM

FT2.wiki wrote:

Note - Log breakage issues are covered in bug 21279.

Add Comment