Last modified: 2014-01-23 19:19:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 18493 - Unify various deletion systems
Unify various deletion systems
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page deletion (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 18104 20290
Blocks: 11402 SWMT
  Show dependency treegraph
 
Reported: 2009-04-17 12:19 UTC by FT2
Modified: 2014-01-23 19:19 UTC (History)
12 users (show)

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


Attachments

Description FT2 2009-04-17 12:19:02 UTC
At present we now have 4 means of deleting material from either the public or from administrators. Material can either be 

* Deleted from the public with traditional deletion
* Deleted from the public (part or full) with RevisionDeleted
* Deleted from admin view with Oversight
* Suppressed from admin view with RevisionDeleted

This collection means that any review of editor actions or conduct, or article matters on the wiki, now faces two big problems in evaluating the existance or seriousness or any issue:

* It's incredibly easy to overlook some edits or actions in the review, which should be taken account of.
* It's more complex and takes examination of several screens, to review a matter.
* Each of these has different mechanisms for viewing edits they affect; there is no consistency of links, formats, access methods, etc.
* A third issue at a technical level - it's a lot to maintain, and allows for inconsistent software behavior (or bugs fixed in one of these but not spotted in the other), and requires more developer time etc.


I would like to suggest that in fact, all we now need is RevisionDeleted, with the following options:

* What to hide - revision text, edit summary, user name/IP
* Whether admins can or can't access the hidden data
* Whether admins or users who cannot access the hidden data, should nonetheless be able to see it exists even if they can't read it (there are cases when this is safe, and cases when it isn't).


This proposal is that RevisionDeleted is amended slightly to show the above options, and then both traditional deleted revisions and oversighted revisions are converted to RevisionDeleted entries as a background task (ie a script written that achieves this in the job queue over time). Following this:

* Delete and oversight both redirect to RevDel for their actions
* Delete/undelete and oversight url's both redirect to the appropriate lookup link for any historical URL used to view an old deleted/oversighted edit.


The issue here is not so much one of software development, as of a once-off conversion task of old data stored in one system to be moved to another.
Comment 1 FT2 2009-04-17 12:20:48 UTC
(2, 3, 4, ... I can't count!)
Comment 2 FT2 2009-04-17 12:24:20 UTC
(Note - this may be agreeable but not practical until admin use of RevDel is enabled, and any significant issues from the rollout of RevDel are addressed)
Comment 3 John Mark Vandenberg 2009-04-29 02:14:44 UTC
See bug 17444.
Comment 4 Happy-melon 2009-04-30 22:07:04 UTC
Would it be sensible to set this bug up as a tracking bug? Its general principle (phase out other forms of oversight in favour of a tweaked-up RevDel) is blocked by most of the other bugs out there.  We certainly need *a* tracker for all this stuff; while compartmentalisation is good, we have a lot of plates spinning at the moment. 
Comment 5 Mike.lifeguard 2009-06-20 13:52:49 UTC
(In reply to comment #4)
> Would it be sensible to set this bug up as a tracking bug? Its general
> principle (phase out other forms of oversight in favour of a tweaked-up RevDel)
> is blocked by most of the other bugs out there.  We certainly need *a* tracker
> for all this stuff; while compartmentalisation is good, we have a lot of plates
> spinning at the moment. 
> 

I've sort-of done that by shifting the depends to blocks on bug 18598.
Comment 6 FT2 2009-08-17 16:57:23 UTC
See also bug 20290, covering a "hide placeholder" option in RevDel. Added the dependency.
Comment 7 Thatcher 2009-08-17 17:06:39 UTC
It's really about time to remove the Oversight extension entirely; that's under discussion.  That would leave only 3 deletion options, which are really 2 (admin deletion and RevDel with optional suppression).

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


Navigation
Links