Possible to prevent upload?

[jstayton]

Hey there,

I have auto-upload disabled to give the user a chance to input a name for each file before upload. If the name is not unique — a check I do with an XHR request in onSubmit — I'd like to prevent the file from being uploaded until the name is unique (checked on keyup). I tried returning false in onUpload, but that doesn't seem to be supported, as the file is still uploaded. I know it's possible to prevent a file from being added, but that doesn't really help in this case. I'd like the file to be added, but prevent upload. Can you think of a way I can accomplish this flow?

I'm using v3.3 of the jQuery plugin.

Love the work you're doing — thanks!

[rnicholus]

I'm a bit confused. You are checking for the existence of a duplicate file in onSubmit, but still allowing the file to be submitted to the uploader? Why? Can you describe your app in some more detail? I feel like I am missing something here. Why do you want to keep the file around if you don't want to upload it? Also, what sort of specific user action coincides with the keyup event you are handling?

Also, since you are using the file name to detect duplicate files, I assume you are not supporting any iOS6 devices at all, is this true?

[jstayton]

Hey Ray,

Thanks for the quick response!

Maybe a screen shot will help:

The text input field is populated with the file name (minus extension) if available. The user can also edit the name if they want. This is the name that's checked for uniqueness. If it's not unique — as the first file in the screen shot depicts — then the user is given the option to overwrite the existing file, or change the name to something unique. Until that happens, I'd like to prevent that file from being uploaded when the "Upload Now" trigger is clicked.

Can you describe your app in some more detail?

It's a CMS with media file management.

Why do you want to keep the file around if you don't want to upload it?

So the user is given the option to overwrite the existing file, or change the name to something unique. I'd prefer to do this on the client-side, rather than having to upload the file and do the check on the server-side.

Also, what sort of specific user action coincides with the keyup event you are handling?

I'm firing off an XHR request to check if the inputted name already exists or not.

Also, since you are using the file name to detect duplicate files, I assume you are not supporting any iOS6 devices at all, is this true?

Good question. If the file name isn't available, I'd like to force the user to input a name for the file manually. Until they do, the file shouldn't be uploaded.

[rnicholus]

I take it your are using FineUploaderBasic mode and sending the file name as a custom parameter along with each file, correct?

I'm firing off an XHR request to check if the inputted name already exists or not.

I'm still a little fuzzy on this keyup event. What key is the user pressing here?

If the file name isn't available, I'd like to force the user to input a name for the file manually. Until they do, the file shouldn't be uploaded.

The problem with iOS6 is that all images have the same name (image.jpg). For some reason, videos have a variable file name though, such as IMG_0095.MOV.

As to your original question, the answer is: there is not currently a way to prevent a submitted file from being uploaded once it hits the onUpload callback handler. Currently, the only way to prevent a file from being uploaded is to prevent it from being submitted (by returning appropriate values in your onSubmit, onValidate or onValidateBatch handlers).

I could certainly allow a false return value from an onUpload handler to prevent that specific file from being uploaded. That's easy. The tricky part is determining what should happen to that item if the return value for that callback is false. There are a few options:

• Treat it as we treat a false return value in onSubmit,onValidate, oronValidateBatch`: remove the file entirely and make it inaccessible.
• Consider the upload a "failure". This would make it possible to upload the file again via the retry API method (or the retry link that would automatically appear next to the file) but only the the retry feature is enabled. If this feature is not enabled, the file is effectively dead.
• If autoUpload is set to "false", we could simply throw the file back into the internal array of "stored" (not yet in-progress) queue. A call to uploadStoredFiles would make another attempt at such files. If autoUpload is set to "true" however, it's not clear how another attempt can be made at uploading these files.

So, there are really two problems here:

1. Making such an enhancement to the library general-purpose enough to cover a number of workflows.
2. Representing a file that has been prevented from uploading in both the UI and internally.

There was a similar request to yours: #671. This request differs from yours in that it requires the user to decide if the file should be skipped or overwitten before the file is completely submitted to the uploader. I kind of like your approach a bit better though. I would like to support your workflow, as I think it may be a workflow that others may want to follow in the future. I just need to give this some thought, given the issues I described above.

[jstayton]

Hey Ray,

Thanks again for the quick response. You've saved me a lot of time where I'd otherwise be spinning my wheels.

I take it your are using FineUploaderBasic mode and sending the file name as a custom parameter along with each file, correct?

Correct.

I'm still a little fuzzy on this keyup event. What key is the user pressing here?

Any key. Just like JS form validators that re-validate fields on keyup, I'm re-validating that the name is unique.

If autoUpload is set to "false", we could simply throw the file back into the internal array of "stored" (not yet in-progress) queue. A call to uploadStoredFiles would make another attempt at such files.

As I'm setting autoUpload to false, this is almost exactly how I pictured it working. Each time uploadStoredFiles is called, it would try to process all queued files. A callback would then be fired for each file to determine whether to upload the file or keep it in the queue.

If autoUpload is set to "true" however, it's not clear how another attempt can be made at uploading these files.

Yeah, this is less clear. From a UX perspective, I like the idea of the files showing up in the list, because then the developer can show a message explaining why the file can't be uploaded, or give a way for the user to resolve the conflict (as in my use case). This is more helpful than not adding/listing the files at all, because the developer then has to build in an alternate display/UI to accomplish the same.

Making such an enhancement to the library general-purpose enough to cover a number of workflows.

Absolutely. As my use case may even change slightly in the future, I'd like more general callback hooks that I can build my specific flow into.

Representing a file that has been prevented from uploading in both the UI and internally.

Yeah. I don't feel knowledgeable enough on the codebase to give an opinion on whether the files should be considered "failed" or some new "waiting" or "invalid" state.

[rnicholus]

Like I said, I like the idea of displaying a "rejected" file and requiring the user to deal with this issue before the file is actually uploaded. A "duplicate" file situation is the only case where this makes sense to me, but perhaps there are other, more specific situations that would benefit from this as well.

It seems like I could provide a way to mark a file as "invalid but salvageable". I can see a specific return value in an onSubmit handler or onValidate handler triggering this. It seems like an API method would be needed to change the state of such an item as well.

I'll need to think about how I represent this file internally, and in the FineUploader UI. This certainly won't be part of 3.6. Maybe 3.7. I'm not sure yet. I'll think about this more over the next few days or so.

[jstayton]

Sounds good. Thanks, Ray!

[rnicholus]

Looks like I considered something like this a while back. See the third item in #797.

[rnicholus]

Maybe the simplest solution is to allow a return value of false or a promise to be returned in an onUpload callback handler. If a file is rejected here, by default, it would appear as "failed". You could utilize the retry API method to re-send it if this failure is tied to some user input or temporary condition. Perhaps the default failure message can be specified in the callback's return value somehow.

[rnicholus]

Note that I'm currently implementing support for a return type of Promise for the onUpload callback in #1917. Rejecting will attempt to auto retry if auto retry is enabled and if the rejected object does not contain a preventRetry: true entry.