Last modified: 2007-05-22 02:23:48 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 T7057, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5057 - New users should be allowed to replace their own uploaded files
New users should be allowed to replace their own uploaded files
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org/wiki/Com...
: shell
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-21 19:01 UTC by Gustav Broberg
Modified: 2007-05-22 02:23 UTC (History)
3 users (show)

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


Attachments

Description Gustav Broberg 2006-02-21 19:01:35 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).
Comment 1 brianna.laugher 2006-03-01 13:21:37 UTC
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! 
Comment 2 Brion Vibber 2006-03-02 02:30:26 UTC
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.
Comment 3 brianna.laugher 2007-05-06 13:50:49 UTC
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.
Comment 4 Aaron Schulz 2007-05-06 14:19:16 UTC
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.
Comment 5 brianna.laugher 2007-05-06 14:34:11 UTC
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.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-06 17:14:51 UTC
(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.
Comment 7 Aaron Schulz 2007-05-06 17:17:03 UTC
(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.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-06 17:22:58 UTC
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.
Comment 9 Aaron Schulz 2007-05-06 18:06:15 UTC
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.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-06 18:18:23 UTC
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.
Comment 11 Aaron Schulz 2007-05-06 20:47:27 UTC
It would constitute an unexpected security change for current websites,
configuring the right is simple enough IMO.
Comment 12 Aaron Schulz 2007-05-06 20:52:27 UTC
Software change done in r21943. It will require a shell user to set it here.
Comment 13 River Tarnell 2007-05-21 18:26:37 UTC
enabled on all wikis
Comment 14 brianna.laugher 2007-05-22 01:24:52 UTC
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 )

Comment 15 Aaron Schulz 2007-05-22 02:23:48 UTC
(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.

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


Navigation
Links