Last modified: 2013-04-22 16:15:50 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 T32625, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30625 - UploadWizard does not handle 'duplicate-archive' errors correctly
UploadWizard does not handle 'duplicate-archive' errors correctly
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
unspecified
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 30643 36150 37125 37126 (view as bug list)
Depends on: 29594
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-29 23:27 UTC by Erik Moeller
Modified: 2013-04-22 16:15 UTC (History)
11 users (show)

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


Attachments
still a problem (42.05 KB, image/png)
2012-08-25 08:49 UTC, Derk-Jan Hartman
Details

Description Erik Moeller 2011-08-29 23:27:26 UTC
The image content hash check for previously deleted files is not surfaced correctly through the UI.

Steps to reproduce: 

Upload a file that's been previously deleted and proceed through the process

Expected behavior:

Failure on first (upload) step that file with the uploaded contents has been previously deleted.

Actual behavior:

Failure on final (publication) step: "Unknown warning: duplicate-archive"
Comment 1 Andre Engels 2011-11-11 10:22:55 UTC
I got the same problem (with failure "An unknown error occurred.") when uploading a file that, as far as I could see, was not equal to the previously deleted one, but only had the same name.
Comment 2 Mark Holmquist 2012-05-11 21:16:39 UTC
The reason there is absolutely no indication of what the server would do is because, when UploadWizard passes in the parameter "ignorewarnings", apart from cleverly avoiding name-conflict errors, the API doesn't return any of the warning data.

This patch fixes it: https://gerrit.wikimedia.org/r/7312

Once that patch gets accepted and merged, I can throw together a patch to UW that will fix this bug fully. Expect it sometime in the near future.
Comment 3 Mark Holmquist 2012-05-22 17:37:08 UTC
*** Bug 36150 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2012-05-23 19:35:52 UTC
We had to revert that version as it was a bit janky.

When there are warnings, the 'warnings' object is an object in JSON output, but when there are none it ends up becoming an array.

The additional check for empty warnings then got added to check for a 0 length attribute, which would be the wrong check on an object.

Warnings such as 'bad-prefix' for 'IMG_132483247.JPG' were getting reported, making it impossible to upload files directly from a camera since those warnings were seen as 'unknown-warning'.
Comment 5 Mark Holmquist 2012-05-29 16:33:27 UTC
There are three new patches for properly dealing with API warnings, one of them to mediawiki/core. This still doesn't fix the root of the issue for this bug (I believe), so again, we need to land these changes before we can seriously address the original issue.
Comment 6 Mark Holmquist 2012-05-29 16:34:20 UTC
First patch: https://gerrit.wikimedia.org/r/9259

Patch to core: https://gerrit.wikimedia.org/r/9261
Comment 7 Mark Holmquist 2012-05-29 16:35:54 UTC
Augh! There needs to be an edit button.

Second patch to UW: https://gerrit.wikimedia.org/r/8728

The second patch to UW should deal with _some_ of the problems associated with deleted files, but not all of them. duplicate-archive is, I think, still not dealt with properly, but more testing is needed.
Comment 8 Mark Holmquist 2012-05-29 20:13:27 UTC
*** Bug 37125 has been marked as a duplicate of this bug. ***
Comment 9 Mark Holmquist 2012-05-29 20:18:45 UTC
*** Bug 37126 has been marked as a duplicate of this bug. ***
Comment 10 Mark Holmquist 2012-06-01 23:30:37 UTC
*** Bug 30643 has been marked as a duplicate of this bug. ***
Comment 12 Mark Holmquist 2012-08-16 16:09:52 UTC
Hi,

Can someone on the CC list of this bug test again on Commons? One of the patches tied to this bug got merged, and I think the behavior may already be greatly improved. If it works, we can close the bug, if it doesn't, there is another patch sitting in Gerrit that could end this bug's reign of terror.

Thanks!
Comment 13 Derk-Jan Hartman 2012-08-25 08:49:08 UTC
Created attachment 11004 [details]
still a problem

Still can't get past this problem.
Comment 14 Derk-Jan Hartman 2012-08-25 10:42:26 UTC
Wow, there is just a multitude of issues here it seems.

First there seems to be code in the initial upload step to check for duplicates. HOWEVER

1: I suspect the warning is actually encountered in setTransported(), and an error is set, but the logic probably overrides this with setSuccess afterwards. No feedback is ever provided and the upload seems just fine

You'll want something like:
if (warnings.duplicate) (or duplicate-archive)
	var dupeFile = warnings.duplicate[0];

"This file is already available as [[File:dupeFile]]." vs. for archived "This file was previously available as [[File:setTransported]]".  "Remove upload/Continue"

2: The archive error was not handled in the final step https://gerrit.wikimedia.org/r/21405

3: The duplicate errors should be ignored in the final step, just as was-deleted (which means you picked a title that previously has existed).

4: The .showError() of UploadDetails is simply non-recoverable. It does not allow you to remove the file that is problematic, and esp. for unknown errors, that is bad. I should allow you to remove the upload so you can continue the other uploads in your list.

5: The .showError() does not surface the 'Continue' and/or "Upload more files" buttons.
Comment 15 Derk-Jan Hartman 2012-08-25 13:44:08 UTC
Did this duplicate stuff ever work ?

I doubt it. It seems it is trying to insert a function to create a dialog into the error msg. 

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84726
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86874
Comment 16 Ryan Kaldari 2012-08-28 01:57:22 UTC
I think this might be fixed now in the trunk version. Can someone verify?
Comment 17 Erik Moeller 2012-08-28 23:34:53 UTC
Confirmed fixed in master, leaving bug open pending deployment and final verification.

(Small UX issue: The big "Retry uploads" button vs. file-specific override actions are a bit confusing. Maybe clean that up down the road.)
Comment 18 Derk-Jan Hartman 2012-09-13 21:45:47 UTC
Deployed now as well, works for me.

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


Navigation
Links