Hard return in file can negatively impact item status import

[Elaine Hardy]

Hard return in file can negatively impact item status import

If a text file contains a hard return with no accompanying data in the same line within the list of barcodes, the import stops at that hard return. For example, if my file is:

50723000443123
50723010107874
50723010116834
50723000013827
50723010092811
50723010155386
¶
50723010108526
50723010005771
50723010075246
50723010117113
50723010068936
50723010106645
50723010100432
50723010100184
50723010065775

The file loads into item status from the bottom up and stops at the hard return, loading only 9 items rather than the 15 in the file.

If the hard return is at the end of the file, the file fails silently.

50723000443123
50723010107874
50723010116834
50723000013827
50723010092811
50723010155386
50723010108526
50723010005771
50723010075246
50723010117113
50723010068936
50723010106645
50723010100432
50723010100184
50723010065775
¶

Having the “empty” hard return at the beginning of the file does not negatively impact the import.

[Andrea Neiman (aneiman)]

Confirmed on recent-ish master

[Josh Stompro (u-launchpad-stompro-org)]

It looks like the code that processes the file of barcodes is at
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/cat/item/app.js;hb=bb6495dd8e2e7a8c8cee4577799b14b061261f21#l285

I wonder if the "if (!line) return;" in the loop function is allowing blank barcodes through? I added some logging and that does seem to be the problem.

Array(18) [ "50723000443123", "50723010107874", "", "50723010116834", "50723000013827", "50723010092811", "50723010155386", "", "50723010108526", "50723010005771", … ]

Blank barcodes are getting through.

Moving the "if (!line) return;" to below the regex seems to solve this issue for me. But I don't get why. What is that regex doing to an empty string that fixes the logical not check?

Josh

[Josh Stompro (u-launchpad-stompro-org)]

I get it now, I'm using windows line endings, CRLF. The CR is remaining after the split and prevents the !line from working, then the regex $ matches the CR and strips it off.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

I'm going to mark this as a duplicate of 1798187, the cause is the same.