Upload files in correct sequence to attachment

[John-Paul_Kerno]

I am trying to upload several jpgs to one record. I use ‘Gallery’ and drop files in bulk to the plus sign bottom right. They are pages from a book and therefore in a sequence. The files are numbered as jpgs in a numerical sequence.

Why can I not have the viewed output remain in the correct sequence?
Why is the output always reversed with the last item first?
How can I fix this?

Many thanks if anybody can help!

[Bill_French]

kuovonne:

This might have to do with the way JavaScript compares strings.

Or possibly that javascript has this little habit of magically changing data types to fit its understanding of the use case. :winking_face:

kuovonne:

return a.filename.localeCompare(b.filename);

A little warning; I typically avoid localeCompare because string comparisons under some locales may be unpredictable.

Old School (and if you ever need to sort null values to the top)

input.sort(({value:a}, {value:b}) => {
  const ai = parseInt(a, 10), bi = parseInt(b, 10);
  return (b == null) - (a == null)
    || (ai - bi)
    || (a > b) - (b > a);
}).map(x => x.value || "")

[John-Paul_Kerno]

Fabulous! Works well for me. Many thanks. Pity that this has to be a script though …

[kuovonne]

I’m glad the script works for you. Could you please mark the post with the script you used as the solution? Both scripts have been updated with the changes discussed.

[John-Paul_Kerno]

Unfortunately there is a problem with this code. I copied and pasted the script into another base and ran on 75 jpgs which come back correct but backwards. I looked at the original ‘success’ in the first base and ran the script again on the item I thought had been ordered correctly but once again it ordered the items backwards. Items have been named in as simple a way as “1.jpg, 2.jpg, 3.jpg …” etc but no success.

I only tested the original solution on three jpgs. Maybe the sheer number causes it to fail?

[Bill_French]

A simple and effective solution to this problem has evaded us; at 40+ threads and despite a bunch of time invested in code by @kuovonne, we are apparently no closer to a resolution.

John-Paul_Kernot:

I only tested the original solution on three jpgs. Maybe the sheer number causes it to fail?

Indeed, and I offered a [predictive] explanation that might cause this approach to fail; briefly - that the attachment architecture is based on an internal Airtable process that is not transparent. We have no idea exactly how Airtable queues, reads, and injects new documents into an attachment field. I’ll say it again -

Until such time as the process can unentangle the imperfections that occur when process (a) asks process (b) to read and ingest documents over HTTP such that the completion outcomes are prescribed in a serial (i.e., ordered fashion), the nature of the outcomes may appear random or at least unpredictable. And even that is not a certainty.

The fact that they are simply reversed (as @John-Paul_Kernot indicates), suggests that the sort polarity is exactly the opposite of the desired outcome; a simple code tweak, right?

That idea aside, let’s revisit my reluctance of this approach:

Bill.French:

~38 message threads ago - I thought about this approach but dismissed it on the fear that Airtable itself might assume the same URLs it initially created would influence how the order would be reestablished, perhaps not even making new image copies and leaving no change whatsoever.

I’ll own this flawed prediction when y’all prove me wrong because I know that if you can influence three files to behave as desired, why not 75 files, right? Seems like a reasonable assumption but all data considered, the probability I’m right about this is pegged at 51%. However, that assumption is based on an incomplete awareness of the black box known as Airtable’s Attachment Ingest architecture which likely has a limit to the number of web-workers in the process which by default injects an uncontrollable variable into the process. :winking_face:

Recommendations:

1. Add a new configuration variable that allows @John-Paul_Kernot to be able to reverse the sort polarity to experiment with the script without modifying the underlying sort code.
2. Modify the code to read from attachment field 1 and write to attachment field 2.
3. If recommendation #1 nor #2 provide relief, we can probably all agree that my suspicions were likely correct and perhaps the only way to control this is by formulating an API process that can manage an ingest pace commensurate with the attributes of document assets themselves working solely with a clean, empty attachments field.

Recommendation #3 takes the position that only one [ingest] web-worker at a time must be allowed to exist to remove the upload completion variability.

[kuovonne]

John-Paul_Kernot:

I copied and pasted the script into another base and ran on 75 jpgs which come back correct but backwards.

Did you change the Show attachments in reverse order toggle for the field as described by @Justin_Barrett in post 5 and in this support article?

---

Another possibility could be due to how JavaScript compares strings and issues with localecompare, as pointed out by @Bill.French.
To reverse the order, you can try changing this line

return a.filename.localeCompare(b.filename);

to this line

return b.filename.localeCompare(a.filename);

---

You can also try using @Bill.French’s alternative to localeCompare.

function sortArray (attachmentArray) {
    return attachmentArray.sort((attachmentA,attachmentB) => {
      const a = attachmentA.filename;
      const b = attachmentB.filename;
      const ai = parseInt(a, 10);
      const bi = parseInt(b,10);
      return ((b == null) - (a == null)) || (ai - bi) || (a > b) - (b > a)
    })
}

[kuovonne]

John-Paul_Kernot:

Pity that this has to be a script though

It would be nice if the Batch Update block sorted attachment fields as well as sorting linked record fields. You could add a product suggestion in the Product Suggestions portion of this community forumn.

[John-Paul_Kerno]

Ok, so I tried again.

1. As I pasted the script into an already set up Base, I did not realise that the attachment field was set to Show attachments in reverse order. Many thanks for pointing this out, I am sorry I don not recall that was an option so failed to diagnose. The attachments now show correctly.

However,

2. I also found out that a sequence “1.jpg, 2.jpg, 3.jpg … 10.jpg, 11.jpg” will fail to list correctly. So, there must be a preceding zero such as "01.jpg, 02.jpg, 03.jpg … ".

Many thanks!

[Bill_French]

John-Paul_Kernot:

a sequence “1.jpg, 2.jpg, 3.jpg … 10.jpg, 11.jpg” will fail to list correctly.

Let me guess… 1.jpg, 10.jpg, 2.jpg…

[John-Paul_Kerno]

Correct! That’s the one.