I have expanded the results of both sets and they are exactly the same. Same non sequential order. The order does not change in the field.

I’m sorry the script does not work for you. As the script works on my setup (as you can see in my screen capture), there isn’t much more I can do.

I hope you find a solution to your problem.

Hi, I figured out that the script will only run on limited number sequences such as

1.jpg

2.jpg

3.jpg

It will not run on leading zeroes

001.jpg

002.jpg

or when the filename has any characters, even if characters preceded by any sequence.

But, it will run when sequence numbers are after any characters (NAME-1.jpg, NAME-2.jpg, but not if the sequence has preceding zeroes, ie NAME-001.jpg, NAME-002.jpg

Thank you for this additional information. This might have to do with the way JavaScript compares strings.

Try replacing this line …

return a.filename > b.filename

with this line …

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

return a.filename > b.filename

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

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

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 || "")

return a.filename > b.filename

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

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

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.

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?

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.

Indeed, and I offered a opredictive] 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:

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 oingest] web-worker at a time must be allowed to exist to remove the upload completion variability.

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)

    })

}

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.

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!

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

Correct! That’s the one.

Indeed, this is a correct sort order. It doesn’t seem logical, but it is. It’s no different than …

• A.jpg


• A0.jpg


• A1.jpg


• B.jpg