Last modified: 2007-05-22 02:23:48 UTC
(I see this is Wikimedia Commons and I haven't been able to test it elsewhere) There seems to be a restriction not allowing new users to overwriting existing files by uploading new ones with the same name (according to this: [http://commons.wikimedia.org/wiki/Commons:Help_desk#Revising_images]). This is all fine. The problem is that it also prevents new users from overwriting files that they _themself_ have created. Obviously, this does not help to stop vandals, it only annoys new users (especially since the error message does not state the correct reason).
I got this warning at en.wp: "A file with this name exists at the Wikimedia Commons. Please go back and upload this file under a new name." Well, I knew that, because the image was a copyvio (album cover) that I was uploading to en for that very reason, because it was about to be deleted. There should be an option to "upload anyway". Especially when I wasn't even overwriting an existing file!
Re comment 1: no, it's not allowed due to the longstanding problems with vandalism of images. Only sysops may locally overwrite Commons images on the local wikis. Also this is unrelated to the bug.
I think this is maybe not too hard to fix. In SpecialUpload.php, function checkOverwrite( $name ) : line 01288: <code> if( !$wgUser->isAllowed( 'reupload' ) ) { </code> change to <code> if ( !$wgUser->isAllowed( 'reupload' ) && !userIsLastUploader( $wgUser, $img ) ) { </code> add this somewhere, I'm not sure where: <code> function userIsLastUploader ( $user, $img ) { $dbr = wfGetDB( DB_SLAVE ); $res = $dbr->select( /* FROM */ 'image', /* SELECT */ 'img_user', /* WHERE */ array( 'img_name' => $img ) ); $img_user = $dbr->fetchObject( $res ); $dbr->freeResult( $res ) ; return $user->getID() == $img_user; } </code> nb. not tested.
Just because someone uploaded image X doesn't mean they can't still vandalize it. Once text/images are submitted they should be treated similarly, regardless of who made it. It may sometimes be needed for new users to delete or move things they just made, but that is best done with assistance, rather than some contrived software change that adds more complexity and instruction creep for minimal gain.
OK just to be clear, this is about non-autoconfirmed users not being able to overwrite ('reupload') their own files. There is no problem with stopping non-autoconfirmed users from overwriting other people's files. New users very frequently make mistakes with their images, more often than other users precisely because they are new. These include: stupid filenames, wrong orientation of image, uploading the wrong file, file doesn't render as expected (very common with SVGs). This is one of the most regular help requests at Commons. Currently users have to upload the new version of the file under another name, find the Help desk and request the move, and an admin has to download the new file, upload it over the old one, delete the old file. It strikes me as a lot of unnecessary work. I don't quite understand the idea that a user would upload an image, and then vandalise it. Stopping non-autoconfirmed users from reuploading doesn't stop them from uploading vandal images, of course. The solution to that problem is still block the user/protect the image on a benign version, isn't it? thanks.
(In reply to comment #4) > Just because someone uploaded image X doesn't mean they can't still vandalize > it. . . . that doesn't make any sense.
(In reply to comment #6) > (In reply to comment #4) > > Just because someone uploaded image X doesn't mean they can't still vandalize > > it. > > . . . that doesn't make any sense. If a user Y uploads image X and it becomes used by page Z, they can still upload a bad version over it if this was allowed, causing page Z to become vandalized too.
They could do that anyway by just editing the page. If the image is so widely used that it would cause widespread damage after less than four days, then obviously they've been very helpful and probably won't vandalize anything.
OK, in order to avoid messing with site's settings when they svn up, this is best done with a new permission, 'reupload-own'. A shell user can add the $wgGroupPermissions line to commons.
I don't see any problem in allowing all users with the upload permission to reupload-own as well even in existing installations. I would call that expected behavior.
It would constitute an unexpected security change for current websites, configuring the right is simple enough IMO.
Software change done in r21943. It will require a shell user to set it here.
enabled on all wikis
Thankyou. I can confirm it works. However the "upload a new version of this file" link doesn't appear on the image page. I think it is because of this line in ImagePage.php: if( $wgUser->isAllowed( 'reupload' ) ) { It should be changed to call this function in SpecialUpload.php: function userCanReUpload( $user, $img )
(In reply to comment #14) > Thankyou. I can confirm it works. > > However the "upload a new version of this file" link doesn't appear on the > image page. I think it is because of this line in ImagePage.php: > > if( $wgUser->isAllowed( 'reupload' ) ) { > > > It should be changed to call this function in SpecialUpload.php: > > function userCanReUpload( $user, $img ) > Right, done in r22312.
