Help

Upload files in correct sequence to attachment

Topic Labels: Views
Solved
Jump to Solution
8005 40
cancel
Showing results for 
Search instead for 
Did you mean: 
John-Paul_Kerno
7 - App Architect
7 - App Architect

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!

40 Replies 40

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

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.

John-Paul_Kerno
7 - App Architect
7 - App Architect

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 [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:

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.

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.

John-Paul_Kerno
7 - App Architect
7 - App Architect

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,

  1. 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.