I import many records at a time using the spreadsheet pasting method. However, then I have to go through and paste each image URL one-by-one into the image field, then hit upload.
It would be great if pasting image URLs during your Bulk Spreadsheet Paste would just detect that it is a URL and auto-upload! Yay!
I upvoted this right away because the only way to do this is to transform the URLs via the API or some other processing using Zapier or Integromat.
However, then I unvoted this idea because there is a very good reason this is not supported. Here are the issues:
Attachment URLs are ostensibly public; anyone can access them without signing in if they somehow find the URL that is created in the attachment. This could be a huge surprise to unsuspecting users.
Attachment fields support many document objects; PDFs, images, videos, etc. and some URLs that simply cannot be uploaded into Airtable.
A default transformation and importing behavior like this is heavy-handed and can’t be easily transformed from attachments to just a URL or text field.
Imagine the performance hit on the Airtable servers if you pasted 10,000 images.
I disagree with your reasoning.
You see… I open every record and paste in the URL, and upload the image as it is from a URL. So, I would just like to do the same thing en masse, instead of doing it by hand for each and every record.
If the URLs are public, then they are already happening that way, but I’m just doing more work. Seems the image address is very obfuscated and random. If they want to put up a disclaimer or warning so people don’t upload important private stuff, then I’m fine with that. Seems the public issue is already there. I am just looking to speed up the logistical process.
Some URLs cannot be uploaded into airtable. Yep, that’s fine. Just output an error that says, “We can’t take that kind.”
As for your 3rd concern, I’m not looking to transform from an attachment to URL or text field. Rather the opposite.
Now as for performance hits. I’m sure the wonderful programmers can create a load balancing function that works on such jobs in a queue while servers are idle. It’s part of their job to prioritize processes. Much like Amazon, Youtube, and many other SaaS products, large jobs uploaded don’t happen immediately, but rather you would receive an email later saying it is finished.
Now, let’s stop finding reasons not to do awesome things, and request for awesome things to happen.
Yep - I fully understood your pain. I don’t like it either. I want to upvote this because it seems right. Other codeless platforms behave this way and in your own words, it’s an awesome pathway to higher productivity. No human should ever have to do anything more than seven times. :winking_face:
Don’t misinterpret the rest of my comments - they are simply observations about the way arbitrary document types are handled and exposed by businesses.
Let’s put a finer point on the term “public”. There are binary artefacts such as images and documents openly hosted on the web, and there are many that are not openly hosted but accessible in secure systems shared to Anyone with Link. These are two similar, but intentionally different accessibilities.
Sharing documents this way is not the same as making them “public”; in fact, they are not public. And they always remain secure until - and at such time - they are exposed. The question is - how are they exposed? By reference or by value?
Airtable further exposes these files by value and this may be in conflict with the intent. Airtable makes a new copy of these artefacts thus not only removing the intended security on the original document, but also making it available for open discoverability by doubling the access surface. If you then remove the original accessibility, it’s too late - the documents are in the wild. One might argue that this is certainly not Airtable’s concern - they cannot be held responsible for unintentional copying legitimately accessible documents by their users. But, if you make this really easy, it could be blamed for copying vast data sets that were intended to be somewhat protected.
As such, I think it may be something that Airtable might want to defend against or at least discourage. Offering a way to do hundreds or thousands in one step could pave the way for some vastly larger collections to replicate what was intended to be protected resources. But I agree - this is almost a semantic point, but it is a very unique semantic that users - by and large - may not fully understand. The argument that Airtable certainly allows anyone to do that one at a time now or in bulk with the API or Zapier, is a hollow defence when someone asserts a security breach.
I understood exactly your direction of travel; I was making the point that Airtable might be giving weight to the flow of attachment data into other parts of the table by formula (which is presently not possible). From Airtable’s perspective, it may be that absorbing links to images (rather than as attachments) is (a) very fast, (b) stored in a form that can be easily moved attachments (pasting) or other fields via formula, and (c ) it preserves the original address of the content. Whereas, if they flow in as attachments, this agility and the origin of the assets evaporate - the links are deleted and replaced by the newly copied version. So, while it may be ideal in some use cases, it is not ideal in many others - perhaps they have intentionally taken the lowest common path. Indeed, it’s not awesome but it also does not rule out some ingestion requirements.
Performance of the document copy for storage in Airtable is but one [performance] element; there are others including the limits to what users may store in a table and as we all have seen, the performance degredation when tables are bulging with large attachments.
Hi Peter, we made an extension that auto-uploads any file URL to an attachment field. You can set it to upload with 1-click all existing attachments (and new ones automatically, no limit).
Attachment URLs are ostensibly public; anyone can access them without signing in if they somehow find the URL that is created in the attachment. This could be a huge surprise to unsuspecting users.
How could this be a surprise? Who is gonna add an attachment to a table, make it public and get shocked the attachment is public as well? This could make sense for other formats, but certainly not images.
Attachment fields support many document objects; PDFs, images, videos, etc. and some URLs that simply cannot be uploaded into Airtable.
Yes. Display error message. We had those literally for decades now.
A default transformation and importing behavior like this is heavy-handed and can’t be easily transformed from attachments to just a URL or text field.
Yes it can.
Imagine the performance hit on the Airtable servers if you pasted 10,000 images.
How this is handled is you put all the attachments into queue and process certain amount over certain period of time. You prioritize based on things like if the user is paying member or the server(s) load. Nothing new. Alternatively, you know, put some limits in place.
Well, this should be a surprise in cases where a user has not made a table public and yet, the attachment URLs are public. It appears I have not stated the issue clear enough. Once a document enters the Airtable CDN, its URLs are accessible despite keeping the table itself private and despite removing public access to the URL where the document was originally loaded from. It’s possible this behaviour may have changed since authoring this message in 2019 - haven’t checked recently.
