Hello

I'm having some bad hours fiddling around with Kendo UI Upload to make what I want. Initially I wanted to restrict specific file types by "validation" parameter AND set the parameter "maxFileSize" depending on file type. This all with the autoupload feature (selecting one or more files). Something like:
.jpg, .png, .gif -> max 1 MB
.mp3 > max 5 MB
.mp4 -> max 10 MB

The world would have been perfect that way. As I was told: Both configuration parameter at the same time are not supported.

Just setting one parameter seems to work great and the Upload Widget does only upload the ones passing the set options. 

Ok, one step back and doing own checks based on e.files while trying to use e.preventDefault(); in select event. Oh great, it prevents ALL files to be uploaded even the valid ones! Why can the Upload Widget itself differ between valid and invalid ones (in order to upload only the valid ones) while I - as programmer - have no chance to define which files are ready to upload and which are not?

Ok, one step back: I tried to remove invalid files from e.files in select event. Guess what: it doesn't matter what I do in here! The upload event has its own list and ignores any operation I have done inside e.files in select event. 

Ok, one step back: where to?

All Kendo UI Widgets have their pros and cons. I'm using many and in some cases I had to and could find a workaround for what I wanted. But the Upload Widget is by far the worst, inconsistent and inflexible Widget in the list! 

Hello Tayger,

You should be able to accomplish such a dynamic solution exactly by using the select event. In this dojo (http://dojo.telerik.com/oluho), the solution implemented prevent uploading files with pdf extension, but let any other files to be uploaded. Similar logic to validate a more complex scenario should be applicable by using the same techique.

Tnx for the anser, you first have come to such a solution! I've tested it out and it doesn't work as it was planned. Furthermore its not usable that way and I will tell you why:

- To make it work I had to add ".pdf" in list of allowedExtensions, otherwise the restriction text of allowedExtensions text is coming up (first) in upload window and would block all further multi selected file uploads. On the other hand: If I would remove allowedExtensions with my actual defined file types I would have to programmatically exclude  - ALL - known file types in the way you did it in your example with PDF. 

- Next problem: Your example works great if you only choose/drag one file. In case its a PDF it works as you said. If its a different file it will uploaded, fine.. If you choose a PDF file AND any other (valid) file(s) at the same time (multi file upload), then ALL files will be uploaded and the message "PDF files cannot be uploaded!" will not pop up! I guess there is no file handler in background of your example (thats probably why all turns red on uploading), so you couldn't be aware of that. I've tested that and my file handler on server side responded correctly: "Server response: Error on reading file doku.pdf", but that tells me that the PDF file was also sent to server, what shouldn't happen! Visually, in upload window it looks quite correct: PDF file is displayed in red but there is no message telling the reason (as it would happen on defined types in invalidFileExtension). So the alert is just a workaround that even wont work (not popping up) on multi file selection.

Even if your example would work as it should I still have the problem to associate invalidMaxFileSize with allowedExtensions. I only can repeat myself: The Upload Widget is way not there where it could/should be....

Regards

Hello Tayger,

The solution suggested indeed fails when files are being dragged over. This seems to be a bug with the Kendo Upload and you can monitor its status from here: https://github.com/telerik/kendo-ui-core/issues/3064. I am also updating your account points due to this report. 

For the time being, I suggest you setting multiple to false so to restrict this bug to affect any validation logic. 

As for the solution, there is no server-side handler that would actually return a success response that the file is uploaded. This is why files are always red and not uploaded. The idea of the suggestion is to validate only on the client. And the fact that pdf file is prevented during the select event means that it is actually never reaching server-side logic at all. The existence of the file in the list after the select event means that it would be sent to the server. For the case here, I do not see why there would be a server-side working example as this is only a client-side file validation topic. 

The idea of the suggested approach is to actually never use the built-in file validation logic and implement a custom one from scratch using the select event. That means that you would not need the  allowedExtensions, maxFileSize or minFileSize options at all. Everything should be programmed in the select handler. 

Also, if you feel that Kendo Upload should provide more flexibility and it should expose more configuration options to fit complex scenario like the one you have, the dev team and the Kendo UI Product Manager will be happy to evaluate and determine the demand for features and improvements. The official channel to suggest ideas, features, improvements or just give some feedback for a particular product is our feedback portal: http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback. 

Hi Ianko

Thank you for the points and way more registering the bug. So I hope it will work with one of the next releases. For the time being I will do as you said and go back to single upload mode. I agree that an invalid file (wrong type, size, ...) that is prevented should never reach the server, even not in a multi upload case.

I'm aware of the possibility to suggest enhancements and I already entered some in the past. The fact that only a very view and only the best rated will be picked up gives me a feeling of playing lottery. So I stopped entering suggestions. 

Regards

Hello Tayger,

I can assure you that the feedback portal is regularly monitored and ideas are evaluated and prioritized by the dev team and our Product Manager. Demand, votes, and popularity dictate the priorities of tasks and thus our planning depends on that.

At the moment, the feedback portal is the best option to give feedback about the products and/or suggest ideas. Therefore, I encourage you to use it as a channel to suggest improvements for our components and give feedback about our product. Although support ticket and forums are also an option to give feedback, they are more dedicated to technical help. The benefits of the feedback portal are that other developers can vote, which would affect priority and the fact that the ideas suggested are directly evaluated by the dev team and the Product Manager. 

Hi Ianko

Please don't get me wrong: It's great Telerik listens to their customer so they can do suggestions. The voting system just allows very vew changes for each Widget so the chance is very low to get required changes. Developers have always project specific requirements that others don't have and therefore will not vote. Nevertheless I will try it (again).