folengo wrote:

*** Bug 30224 has been marked as a duplicate of this bug. ***

saibotrash wrote:

An example
http://commons.wikimedia.org/w/index.php?title=Commons:Prototype_upload_wizard_feedback&oldid=58230793#RE:_not_allowing_me_to_upload_my_picture

In that case it should give the uploader the option to upload anyway.

I do not see why we should change the behaviour know from the old form. http://commons.wikimedia.org/w/index.php?title=Special:Upload&wpDestFile=Test_upload_for_neil.jpg it gives a warning on top and right below the file name but allows to upload anyway.

UW should present such a warning if possible directly when entering the name - telling that a file with this file name was deleted before blabla. If it is only checked in the last step UW should warn and allow to go back and change the file name or to upload anyway. And give a warning that this should usually not be done if a file was deleted because of copyvio.

There are two separate issues described in this bug, which possibly should be split into two bugs.

1. Making it more intuitive to start over when a batch is unsuccessful. Currently, the only way to do so is to manually remove the files from the batch (by mousing over them and clicking "remove"). I would suggest a "Start over" button or something similar when a batch has errors, which would have the same effect as removing all files individually.

2. Making it possible to override additional error conditions. Yes, this is possible in the old form, although the UI and workflow is pretty horrible (your file may have multiple error conditions, and you may have to go through multiple submits, and discover the "Ignore warnings and save anyway", to finally be able to push it through).

Saibo, to be clear about the different checks: UploadWizard already handles filename conflicts very gracefully most of the time. Because of the way files are stored in the stash, title issues don't have to be resolved until the "Describe" step, at which point interactive JavaScript gives you hints about needed renames. There's bug 30646, but other than that, I believe files should never fail on the first step for title reasons.

The checks you're describing check the actual _contents_ of the file. So we're talking about a use case where you can override the _exact same file_ that's been previously deleted, or that exists in another copy.

I agree that it should be possible to override "previously deleted" files. While blocking such files may have some vandalism fighting benefits, it's fundamentally not very user-friendly, and as your link proves, it may cause unrecoverable issues for users.

I am not sure I see the use case for overriding "duplicate content" files. Can you give a real world example where that would actually be desirable?

As for the override UI: One reasonably (although not perfectly) discoverable mechanism to do per-file overrides might be to have an "Upload anyway" button next to the "Remove" link that appears on mouseover per file, which would act as an instant resolution (turning from "Warning" to "OK") for that upload.

Reducing importance to "normal" for now as neither issue appears like a major pain point relative to other remaining issues.

This appears to be fixed in master, I get the "another file exists" at the first step, allowing me the option to remove it or what have you. There is one patch (https://gerrit.wikimedia.org/r/8937) that would fix at least one potential problem, and another (https://gerrit.wikimedia.org/r/#/c/8728/) that should fix another one. If there are still issues, we should open a different bug, but "file exists, error happens" is now a smooth operation, so I'm going to close this one.

Blocking previously deleted files by protection (which is used on Commons, Erik informs me) is supported, though I forget how well (I believe I've worked on it, I can't find the patch), and was-deleted warnings (for filenames) are now totally ignored (https://gerrit.wikimedia.org/r/#/c/8728/), and though duplicate-archive errors are still a menace to society, there is work being done on bug 30625.

I don't think this is a relevant bug any longer, since the initial problem is now solved and the tangential problems all have patches in the tubes and/or their own bugs. Resolving as fixed.

I just tried again using the latest code, and now I don't get any error, I get to the point where I can "describe" the file, click on Next, and then I get "This file was previously uploaded to this wiki." and still without any way back!

Reopening this bug.

Ah yes, OK, here's the story:

There are currently a few patches of mine awaiting review (https://gerrit.wikimedia.org/r/#/q/UploadWizard+owner:MarkTraceur+is:open,n,z) and two of those play exactly into this bug. The most important one is the patch to mediawiki/core, which surfaces these errors to be acted upon by the interface. However, there appears to be a huge backlog that isn't getting any smaller, so we may be waiting a while.

In any case, as my excited post above indicates, once that patch is appled, it *will* be fixed. So I'll come back and let you know when it is.

Patch reviewers, here it is: https://gerrit.wikimedia.org/r/9261

Derk-Jan, why did you close this bug? I tried again using latest master code and I don't see any differences...

This should be fixed with https://gerrit.wikimedia.org/r/10995

Tested again, and indeed now it notifies me of an already uploaded file during the upload step, which is much better.

Closing now, thanks!