Renaming a long attachment filename

Hello community!

This is my first Airtable script. I’ve been proud so far but there’s a detail that I cannot crack.

The situation is: I’m generating a dynamic chart via using Airtable fields and I want to create a .png file from it to send by email.
So I created a formula field that generates the appropriate URL for the chart, this works perfectly.
Then, I created a script that runs upon that URL being updated, here’s the kink.

The script is based on a similar Airtable script which takes a URL and creates a file in another column on the same table.

The issue is that the ´filename´ is not being updated. It creates the file perfectly, but the filename is taken as a part of the URL which is unreadable and doesn’t contain the file extension.

Here’s my take:

let table = base.getTable("Table 5");
let attachmentField = table.getField("Attachments")
let inVar = input.config();
let url = inVar.Attachment_URL;

let updates = [];
let attachmentUrl = [{url: url, filename: 'Chart.png'}]; //does NOT change filename
    id: inVar.Record_ID,
    fields: {
        "Attachments": [

await table.updateRecordsAsync(updates);


//Check filename
let recordsAll = await table.selectRecordsAsync({ fields: [attachmentField] });
let record = recordsAll.getRecord(inVar.Record_ID);

My issue might sound silly (and I hope it has a simple solution), but it’s very important; the users will receive the file by email, so the current name is extremely sketchy. I’d like them to trust the file they receive (they will be expecting one!)

Here’s a sample picture:

Any help or idea in getting the filename right is greatly appreciated!

If I delete the URL and paste it again in the field, sometimes the filename is changed correctly (see picture).

So I think the script itself is not the problem. Still, this is not a consistent behaviour and it would be great if the filename was always the correct one.

You are remarkably close, I think.

The way to approach these kinds of issues is backwards, especially seeing how svelte this code is.

For starters, I’d replace the string literals on line 8 with template literals or another referential value. That’s where your code is failing.

Concurrency craziness is what I’d point to if you wanted an explanation for why some of the URLs are fine on an occasion (some of those await timings are suspect at a first glance). That’s a testament to whatever Airtable’s doing to keep the failure rate of its attachment field as low as possible (and let’s be real, that’s probably their number one most troublesome field by some margin).

And if you open all those records your script “hasn’t been changing”, you’ll likely see that the filename field has been updated on quite a few occasions - with the exact same filename. You need a system for dynamic file naming and you probably need it even before the image leaves the quickcharts servers.

As for this peculiarity:

What this line says to the JS interpter in your browser is: url variable goes to the url reference field, and for the filename field, just write “Chart.png”. You then plug it into a table-wide loop and end up scratching your head over why the code isn’t doing anything when it is, in fact, doing an extraordinarily good job at wasting your electricity. :sweat_smile:

Hi Dominik!

Thanks for the reply!

I did what you suggested and changed the string literal with template literals. And it worked :grinning:

let inVar = input.config();
let url = inVar.Attachment_URL;
let companyname = inVar.Company
let datename = inVar.Created_Time.toString().substring(0,10);
let filename = `Result ${companyname} ${datename}.png`;

let attachmentUrl = [{url: url, filename: filename}];

Thank you!

1 Like

By the way, I also found a cache “issue”.
Basically, I was testing with the same image. Thus, the name was exactly the same no matter how I changed the code (even if it was in a different row). I only saw a different result when I changed the image I was working with.

This topic was solved and automatically closed 3 days after the last reply. New replies are no longer allowed.