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.

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. ;-)

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.

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.

• Bug 19697 has been marked as a duplicate of this bug. ***

• Bug 19819 has been marked as a duplicate of this bug. ***

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?

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

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

• 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.

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.

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).

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.

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.

jake wrote:

I get it now. That is quite a problem.

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.

(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.

mike.lifeguard+bugs wrote:

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

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.

(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.

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

FT2.wiki wrote:

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

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.

FT2.wiki wrote:

Note - Log breakage issues are covered in bug 21279.