I’ve spent some time building my image uploader, and will be using same techniques for file uploader. Unfortunately I am at this point not using the multi-file uploader, but instead using the single picture uploader.
Some issues that were mentioned in this thread about files uploaded automatically and being stuck in the file manager taking up space, I found some solutions for some scenarios.
Currently I am limiting the file size of an image, this will help with pricing the app for various plans and the corresponding storage capacity. My workflows have some conditionals to automatically delete files that are larger than the maximum allowed.
See this post
Then from there I wanted to give the user the ability to also “delete” the file from the database and file manager after they uploaded it.
What I needed to do in workflow was to delete the image using a url (bubble default operation) to delete it from the file manager. To ensure I could reference the right URL for the image I had saved it as a data field on the image data type in my D.B.
I believe using this strategy should help with some files uploaded to the file manager that are not wanted. Although I don’t think it is very helpful in case the session is lost somehow, but having the file saved to the D.B. upon upload with a URL as a data field should help make it easier to set up an API workflow on a list of files/images with status “draft” so you could create the list of all files status=draft and delete the files referencing each items link.
@sudsy do you think this set up would work out in the long run? Any ideas of how to improve or places it is shoddy?
At this point I am trying to carefully consider the impact of file uploads on my storage costs as I want to have my app image/file heavy but limit users abilities based on pricing tiers. I wasn’t aware of the file manager upload prior to this thread.