Uploaded files which are deleted can now be undeleted; admins can also view the deleted files without actually undeleting them. This is integrated into the existing Special:Undelete in what I hope is a fairly clear and intuitive manner.
It's my hope that this will encourage admins to tackle the deletion backlogs a little more aggressively, since mistakes will be easier to undo.
I've tested it both offline and on the live servers and everything seems fine so far, but if you do encounter problems please report them at http://bugzilla.wikimedia.org/
-- brion vibber (brion @ pobox.com)
On 6/16/06, Brion Vibber brion@pobox.com wrote:
Uploaded files which are deleted can now be undeleted; admins can also view the deleted files without actually undeleting them. This is integrated into the existing Special:Undelete in what I hope is a fairly clear and intuitive manner.
It's my hope that this will encourage admins to tackle the deletion backlogs a little more aggressively, since mistakes will be easier to undo.
I've tested it both offline and on the live servers and everything seems fine so far, but if you do encounter problems please report them at http://bugzilla.wikimedia.org/
Good this means I can stop maintaining an offsite copy of images from en and nagging for en image dumps.
Brion Vibber wrote:
Uploaded files which are deleted can now be undeleted; admins can also view the deleted files without actually undeleting them. This is integrated into the existing Special:Undelete in what I hope is a fairly clear and intuitive manner.
Brilliant! Thank you very much for this!
Now, when will we have file renames? ;-)
Timwi
Timwi wrote:
Brion Vibber wrote:
Uploaded files which are deleted can now be undeleted; admins can also view the deleted files without actually undeleting them. This is integrated into the existing Special:Undelete in what I hope is a fairly clear and intuitive manner.
Brilliant! Thank you very much for this!
Now, when will we have file renames? ;-)
When the primary file storage is migrated to the hash-based filestore, that will decouple physical filenames from logical filenames and make that feasible.
I do want to make sure it's done before the end of the year, but it's not a top priority (and we want to be damn sure migration will work correctly when it happens; we'll have near half a terabyte of data to migrate when the time comes!) so it won't be tomorrow.
-- brion vibber (brion @ pobox.com)
On 6/18/06, Brion Vibber brion@pobox.com wrote:
When the primary file storage is migrated to the hash-based filestore, that will decouple physical filenames from logical filenames and make that feasible.
I do want to make sure it's done before the end of the year, but it's not a top priority (and we want to be damn sure migration will work correctly when it happens; we'll have near half a terabyte of data to migrate when the time comes!) so it won't be tomorrow.
Would any kind of hack usable by non-admins be conceivable? I mean, considering that a rename can be modelled simple as a copy followed by a delete...being able to rename would do wonders for file naming consistency.
Steve
On 18/06/06, Steve Bennett stevage@gmail.com wrote:
Would any kind of hack usable by non-admins be conceivable? I mean, considering that a rename can be modelled simple as a copy followed by a delete...being able to rename would do wonders for file naming consistency.
Hacks are what get us into this kind of mess in the first place. Implement a clean solution, or don't implement one at all. There's a difference between hacking around a shortcoming in PHP, or writing a dodgy bit of code in a nonessential place, and making a bloody mess in a major function that'll take weeks (and a lot of Domestos) to clean up after.
Rob Church
wikitech-l@lists.wikimedia.org