trailing spaces not trimmed from barcode pastes in item status

[Jim Keenan]

Evergreen 2.5.5

When copying and pasting a barcode from the public OPAC into the barcode field of the staff client Item Status screen, staff may inadvertently pick up an extra, invisible character at the end of the barcode. Example (in hex)

3 8 1 2 5 0 0 0 5 3 6 3 8 4
33 38 31 32 35 30 30 30 35 33 36 33 38 34 09

This copy has picked up the horizontal tab character (09) from the OPAC.

When pasted into the Item Status screen, this will result in the error "was either mis-scanned or is not cataloged" because the trailing 09 character was not trimmed.

[Terran McCanna (tmccanna)]

This is an issue with a lot of fields on a lot of screens. I'm having trouble thinking of any field where we would actually want a leading or trailing space to be stored in a field - should there be a standard of trimming all leading/trailing spaces everywhere? Are there reasons we would not want that?

[Rogan Hamby (rogan-hamby)]

I'm looking at this more broadly in https://bugs.launchpad.net/evergreen/+bug/1332651 which is a duplicate of Terran's comment. However, this specific issue is no longer true with the angular item status screen so I'm going to mark this as invalid since it was never targeted to any milestones.

[Rogan Hamby (rogan-hamby)]

Correction, invalid isn't a good fix given description, marking won't fix. Kind of wish we had a "was valid but isn't any longer" status.