brianna.laugher wrote:

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.

brianna.laugher wrote:

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.

brianna.laugher wrote:

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.

ayg wrote:

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

ayg wrote:

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.

ayg wrote:

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.

river wrote:

enabled on all wikis

brianna.laugher wrote:

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.