This message was deleted.

Hi @gifted-leather-56422, We’ve received that email only now too. This would indeed break our attachments functionality. Fortunately, November 8th is still a long way off. We will look into ways of providing attachments and to continue supporting them in the best way we can, but I don’t have the specifics yet.

Great!

Glad to hear. This was one of the biggest security flaws in Airtable.

It was a security flaw, but their way of fixing it is raw shit. I can’t believe they’re doing it this way, it’s gonna break so many use cases. My hate for them just grew a bit more. Hopefully, Stacker can come to our help, but all existing attachments will need to be re-uploaded (I assume) and this is just so much wasted time.

We ended up implementing our own Firebase AND AWS serverless function to provide this functionality. Glad its now core, can see how it will be more work/annoying for Stacker. But its definitely a solvable problem :)

@clever-art-10420 I’d definitely be interested by a short video demo on how you actually use that! 🙂

I’ll make one for you 🙂

@clever-art-10420 send over my way too if you can?

ok will do - cool to see such interest. it was a random hack we did at some point

Both are helpful! :)

Hey folks. Upon further investigation, the team believes we shouldn’t be impacted by this change because of the way we fetch updates. We will of course continue to monitor the discourse and more details as they emerge.

@elegant-eve-85294 I see what you mean, this is only partially true, unfortunately. Indeed, because you update your cache frequently, you should always use an up-to-date value of the public link. Meaning, when fetching an attachment from Airtable, you’ll fetch the correct public link that is still valid. And when that link changes due to Airtable’s new behavior, you’ll update your cache within 15mn. Although, your cache update might come too late and for a few minutes the attachment will show a 404 page (most likely not show anything at all), and this every few hours. This won’t be good enough. But, even worse, all our automations and actions based on formula will cease to work. This is far more of an issue and can only be solved by Stacker. If you send an attachment link in an email, the link being an Airtable formula, the link will only be valid for a few hours, but then it will display a 404 page. What we need to avoid any regression, is for you to store all the files we upload not on Airtable, but on another provider, and store that link into Airtable. On our side, we will need to replace our current formula by Url fields that are filled by Stacker. We may keep the Airtable Attachment field for some use case, but we will need to have a URL field for all the other use cases in and out of stacker.

Thanks for sharing your thoughts, Ambroise. Can you please add this to your question in #CMZK26G76 to keep all the important information in one place? It will make it easier for the team to track and give you a proper response to all of your points.

@sticky-night-20812 Sorry its going to take me a few days to get back to you as I just moved from NZ to Sweden and am just getting things in order, but I haven’t forgot. I think the code I have will be a viable solution for your above described situation (that is if Stacker don’t solve it themselves). Specifically we use a google storage bucket and then create an expiring url (you can set the time to what you want). We actually used it to integrate a custom pdf generator we built to upload pdfs via expiring urls through the Airtable Rest Api. But there is no reason Airtable couldn’t be the origin of the blob/attachment and then you put it in the bucket and save back the url into airtable, then use this to trigger you email automations.