Last modified: 2011-12-14 17:37:32 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 T28214, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26214 - wpUploadIgnoreWarning not working
wpUploadIgnoreWarning not working
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.17.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-03 00:29 UTC by Platonides
Modified: 2011-12-14 17:37 UTC (History)
3 users (show)

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


Attachments

Description Platonides 2010-12-03 00:29:00 UTC
On trunk version, uploading a duplicate with a different name, pressing either wpUpload or wpUploadIgnoreWarning seem to cancel it.
Back to Special:Upload in both cases, no edit to the original page.
Comment 1 Platonides 2010-12-03 21:25:42 UTC
Are you sure it belongs to UploadWizard? It happens in the normal Special:Upload
Comment 2 Neil Kandalgaonkar 2010-12-03 21:45:17 UTC
(In reply to comment #0)
> On trunk version, uploading a duplicate with a different name, pressing either
> wpUpload or wpUploadIgnoreWarning seem to cancel it.
> Back to Special:Upload in both cases, no edit to the original page.

I don't understand this report, and it doesn't seem to apply to UploadWizard...

UploadWizard doesn't handle the duplicate case properly yet but you seem to be talking about something else.
Comment 3 Bryan Tong Minh 2010-12-03 22:13:20 UTC
I'm sorry, somehow I read it as "wpUploadIgnoreWizard" or something :)
Comment 4 Bryan Tong Minh 2011-01-29 22:00:33 UTC
I think this is the same bug as bug 26929. Platonides, can you confirm?
Comment 5 Platonides 2011-01-29 23:03:23 UTC
Bug 26929 is about the text being wrong. This is a functionality bug about buttons which do nothing. It's still present in current trunk.

Steps to reproduce:
0- Have an uploaded file A with name A
1- Go to Special:Upload
2- Choose to the same source file but place a different name (B).
3- Press upload
You are sent to an intermediate page (this file is already uploaded with a different name), with three buttons:

* wpUpload is supposed to perform an edit in the description page ([[File:A]])
* wpUploadIgnoreWarning is supposed to upload the duplicate with name B, just as if the "Ignore warnings" checkbox had been checked.
* wpCancelUpload sends you back to Special:Upload

The three of them send you back to Special:Upload. The labeled actions are not even done in the background.

This bug was filled pre-branch, marking as blocker for 1.17.
Comment 6 Bryan Tong Minh 2011-01-29 23:10:42 UTC
Sigh... I don't know what it is with this bug report, but I keep on misreading stuff...

I meant bug 27021, and from your description this is definitely the same bug.

*** This bug has been marked as a duplicate of bug 27021 ***
Comment 7 Platonides 2011-01-29 23:44:26 UTC
Heh, that other bug makes more sense :)

r81197 only fixed the wpUploadIgnoreWarning button (which was the only issue reported in bug 27021).

Reopening for wpUpload
Comment 8 Bryan Tong Minh 2011-01-30 14:19:39 UTC
(In reply to comment #7)
> Heh, that other bug makes more sense :)
> 
> r81197 only fixed the wpUploadIgnoreWarning button (which was the only issue
> reported in bug 27021).
> 
> Reopening for wpUpload

Clicking wpUpload gives you again the warning, which is more or less the intention. Or are you refering to another behaviour?
A dupe warning can only be overriden by clicking wpUploadWarning. This is perhaps not very intuitive. In any case this behaviour was already present in 1.16, so should not be a blocker.
Comment 9 Platonides 2011-01-30 14:24:45 UTC
That wpUpload uses label upload-tryagain ('Submit modified file description'). It seems intended to add a new text revision to the description page of the existing file.
Comment 10 Bryan Tong Minh 2011-01-30 14:28:29 UTC
The bug is the label text, it may be interpreted in different ways, and the way you are interpreting it (and most others probably would) is not what it is supposed to do.
Comment 11 Platonides 2011-01-30 15:20:23 UTC
How should it be interpreted?
Changing the description page seemed sensible, given that some people reupload files with a different summary trying to modify the description.
Comment 12 Mark A. Hershberger 2011-02-02 20:05:45 UTC
Not a blocker. Looks like it was there in 1.16.

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


Navigation
Links