| Eloquence | |
| Aug 29 2011, 11:27 PM |
| F7978: Screen_Shot_2012-08-25_at_10.44.43.png | |
| Nov 21 2014, 11:47 PM |
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"
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T32625 UploadWizard does not handle 'duplicate-archive' errors correctly | |||
| Resolved | None | T31594 Need a way back when trying to upload a file in UploadWizard that already exists |
andreengels wrote:
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.
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.
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'.
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.
First patch: https://gerrit.wikimedia.org/r/9259
Patch to core: https://gerrit.wikimedia.org/r/9261
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.
saibotrash wrote:
still - user report: https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&oldid=73314455#Unknown_warning:_.22duplicate-archive.22.
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!
Created attachment 11004
still a problem
Still can't get past this problem.
Attached:
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.
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
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.)