Last modified: 2012-10-29 16:39:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20780, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18780 - Enable RevisionDelete on WMF wikis for admins
Enable RevisionDelete on WMF wikis for admins
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal enhancement with 16 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
Depends on: 20186 20928 21279 23329
Blocks: SWMT 19819 21165
  Show dependency treegraph
 
Reported: 2009-05-13 02:25 UTC by MZMcBride
Modified: 2012-10-29 16:39 UTC (History)
31 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2009-05-13 02:25:53 UTC
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.
Comment 1 Brion Vibber 2009-05-14 23:40:50 UTC
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.
Comment 2 MZMcBride 2009-05-15 00:06:57 UTC
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. ;-)
Comment 3 Mike.lifeguard 2009-06-03 23:26:26 UTC
(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.
Comment 4 ChrisiPK 2009-06-03 23:31:52 UTC
(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.
Comment 5 Alexandre Emsenhuber [IAlex] 2009-07-27 18:32:41 UTC
*** Bug 19697 has been marked as a duplicate of this bug. ***
Comment 6 Alexandre Emsenhuber [IAlex] 2009-07-27 18:33:07 UTC
*** Bug 19819 has been marked as a duplicate of this bug. ***
Comment 7 Mike.lifeguard 2009-08-05 03:31:17 UTC
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?
Comment 8 Mike.lifeguard 2009-08-10 23:10:15 UTC
(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
Comment 9 Brion Vibber 2009-08-10 23:27:38 UTC
Assigning this to me to double-check anything else we need to do before setting
it up...

Comment 10 MZMcBride 2009-08-11 06:27:36 UTC
* 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.
Comment 11 en:Fl 2009-11-23 07:23:50 UTC
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.
Comment 12 FT2 2009-12-01 08:02:43 UTC
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).
Comment 13 Jake Wartenberg 2009-12-01 21:33:41 UTC
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.
Comment 14 FT2 2009-12-01 22:35:10 UTC
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.
Comment 15 Jake Wartenberg 2009-12-01 22:46:50 UTC
I get it now.  That is quite a problem.
Comment 16 David 2009-12-09 17:30:04 UTC
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.
Comment 17 DerHexer 2009-12-11 17:18:43 UTC
(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.
Comment 18 Mike.lifeguard 2010-04-26 07:03:32 UTC
Is Aaron still tasked with revision deletion stuff? Has anyone made a decision about the blockers yet?
Comment 19 xenocidic 2010-04-26 19:45:19 UTC
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.
Comment 20 DerHexer 2010-04-26 20:28:49 UTC
(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.
Comment 21 Krinkle 2010-05-18 14:06:01 UTC
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
Comment 22 FT2 2010-05-19 00:48:38 UTC
Following discussion Werdna is considering this one along witht he others involved. Reopening until the decision is finalized.
Comment 23 Casey Brown 2010-05-19 02:14:57 UTC
(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.
Comment 24 FT2 2011-03-17 13:15:52 UTC
Note - Log breakage issues are covered in bug 21279.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links