Last modified: 2012-04-16 09:16:01 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 T30034, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28034 - uploading file to local wiki when file exists on shared repository (commons) gives spurious info in the warning message
uploading file to local wiki when file exists on shared repository (commons) ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 27339
  Show dependency treegraph
 
Reported: 2011-03-14 00:51 UTC by chzz
Modified: 2012-04-16 09:16 UTC (History)
3 users (show)

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


Attachments
image showing issue (95.39 KB, image/png)
2011-03-14 22:14 UTC, Sam Reed (reedy)
Details
Somewhat proposed fix... (1.52 KB, patch)
2011-03-14 23:06 UTC, Sam Reed (reedy)
Details

Description chzz 2011-03-14 00:51:04 UTC
If a filename exists on commons, and a non-admin (ie without the (reupload-shared) right) tries to upload to the same name on enwiki, it displays;

Upload warning

A file with this name exists at the Wikimedia Commons. You can:

* go back and upload this file to Wikipedia using a different name.

* upload it to Commons, if your intent is to replace the image that already exists with a better version.

File:$1

      $1

...ie literally, "$1" instead of, presumably, showing the file.

I've also documented this issue on the enwiki page where this problem came up;

http://en.wikipedia.org/wiki/Wikipedia_talk:File_mover#Shadow_image

(It'd be nice if, when fixed, someone could append a little note there)
Comment 1 Sam Reed (reedy) 2011-03-14 00:53:43 UTC
Guessing it's due to...

SpecialUpload.php line 450 onwards

		// Verify permissions for this title
		$permErrors = $this->mUpload->verifyPermissions( $wgUser );
		if( $permErrors !== true ) {
			$code = array_shift( $permErrors[0] );
			$this->showRecoverableUploadError( wfMsgExt( $code,
					'parseinline', $permErrors[0] ) );
			return;
		}

We don't seem to pass any sort of parameter...
Comment 2 Sam Reed (reedy) 2011-03-14 20:54:05 UTC
r70135 looks to be the cause...
Comment 3 Sam Reed (reedy) 2011-03-14 21:20:33 UTC
I'm having trouble actually reproducing this one...

http://commons.wikimedia.org/wiki/File:ReedyTestLol.png and then uploading http://en.wikipedia.org/wiki/File:ReedyTestLol.png to enwiki, it told me it existed (ie like "A file with this name exists already. Please check File:Chzz test image.jpg before overwriting"), I just continued, and it let me upload it in place...

This is a WFM at the moment. Can't reproduce it locally, it just doesn't seem to care much.

Halp?

So step 3 I'm currently struggling with. We know the first error message is correct, and also, so is the "can't move over commons image", it's just the one in the middle.

Will ping on the listed talk page also.
Comment 4 chzz 2011-03-14 22:03:24 UTC
(In reply to comment #3)
> I'm having trouble actually reproducing this one...
> 
> http://commons.wikimedia.org/wiki/File:ReedyTestLol.png and then uploading
> http://en.wikipedia.org/wiki/File:ReedyTestLol.png to enwiki, it told me it
> existed (ie like "A file with this name exists already. Please check File:Chzz
> test image.jpg before overwriting"), I just continued, and it let me upload it
> in place...
> 
> This is a WFM at the moment. Can't reproduce it locally, it just doesn't seem
> to care much.
> 
> Halp?
> 
> So step 3 I'm currently struggling with. We know the first error message is
> correct, and also, so is the "can't move over commons image", it's just the one
> in the middle.
> 
> Will ping on the listed talk page also.

I was pung! Thanks;

It will be because of SysOp - more specifically, because SysOp has the (<tt>reupload-shared</tt>) right. So you'd have to test it with a non-admin account. But, it'd have to be a (<tt>confirmed</tt>) or 'auto-confirmed' account to allow upload.

If there's anything I can do, let me know. Thanks for looking.
Comment 5 Sam Reed (reedy) 2011-03-14 22:08:49 UTC
Bingo, got it using my bot account. Taa! :)
Comment 6 Sam Reed (reedy) 2011-03-14 22:14:26 UTC
Created attachment 8295 [details]
image showing issue
Comment 7 Sam Reed (reedy) 2011-03-14 22:20:40 UTC
Definitely http://en.wikipedia.org/wiki/MediaWiki:Fileexists-shared-forbidden

atm it is:
A file with this name exists at the [[Wikimedia Commons]].  You can:
* go back and upload this file to Wikipedia using a different name.  
* [[:commons:Special:Upload|upload it to Commons]], if your intent is to replace the image that already exists with a better version.  [[File:$1|thumb|center|$1]]


Raw message is:
'fileexists-shared-forbidden' => 'A file with this name exists already in the shared file repository.
If you still want to upload your file, please go back and use a new name.
[[File:$1|thumb|center|$1]]',

Need to reproduce it locally now :)
Comment 8 Sam Reed (reedy) 2011-03-14 23:06:11 UTC
Ok, had to hack the core to get it to through me that error (the check for $user->isAllowed( 'reupload-shared' )

The issue seems to be the way

$code = array_shift( $permErrors[0] );
$this->showRecoverableUploadError( wfMsgExt( $code,
      'parseinline', $permErrors[0] ) );

is working

We're only currently returning a string, not the file name. I see the same issue for 'fileexists-forbidden' in the same checkOverwrite method.

The fix I can see is changing it

from
return 'fileexists-shared-forbidden';

to

return array( 'fileexists-shared-forbidden', $file->getName() );

Which then gets double array wrapped by verifyPermissions

		$overwriteError = $this->checkOverwrite( $user );
		if ( $overwriteError !== true ) {
			return array( array( $overwriteError ) );
		}


Changing the code in SpecialUpload to 			

			$code = array_shift( $permErrors[0] );

			$this->showRecoverableUploadError( wfMsgExt( $code[0],
					'parseinline', $code[1] ) );

will then fix it.

I've just no idea if/how that'll actually break the more generic permission checks. I'm not sure on their format, but I'm guessing it probably will.

Will attach a patch with these propose changed


The fix might actually be changing

			$code = array_shift( $permErrors[0] );
			$this->showRecoverableUploadError( wfMsgExt( $code,
					'parseinline', $permErrors[0] ) );

into something that the $permErrors[0] is replaced by some variant of $file->getName();


Need to defer to Bryan/thedj for advice on whether I'll break the current error handling (which looks vague at best currently). Patch incoming
Comment 9 Sam Reed (reedy) 2011-03-14 23:06:48 UTC
Created attachment 8296 [details]
Somewhat proposed fix...
Comment 10 Sam Reed (reedy) 2011-03-14 23:33:55 UTC
Permissions error from no protect rights..


array
  0 => 
    array
      0 => string 'badaccess-groups' (length=16)
      1 => string '[[ReedyDevWiki:Administrators|Administrators]]' (length=46)
      2 => int 1

I'm taking my fix as being right...

'badaccess-groups' => 'The action you have requested is limited to users in {{PLURAL:$2|the group|one of the groups}}: $1.',

Message is index 0, $1 is index 1

Committed with 1 minor tweak in r83979

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


Navigation
Links