Docs: We should document Evergreen's barcode requirements

[Jane Sandberg]

Breaking this off from the discussion here: https://bugs.launchpad.net/evergreen/+bug/1798187 (comments 14-17). Item barcodes should not contain spaces. I'm not sure what the requirements are for patron barcodes. Are there other restrictions that various Evergreen screens put on barcodes?

[Elaine Hardy (ehardy)]

Item barcode format is generally Codabar 13. That is what format is considered for the check digit option (at least it used to be!)

[Rogan Hamby (rogan-hamby)]

Evergreen really doesn't have a barcode requirement in the sense of a standard like Codabar. Those standards are used by barcodes scanners to create a string that is then passed to Evergreen. Someone could create a whole new barcode standard we've never heard of and so long as the scanner passes the string to Evergreen it is fine. The only requirements are when things happen that cause issues with parsing barcodes. So, in regards to https://bugs.launchpad.net/evergreen/+bug/1798187 the space is, for now, a bad thing (tm) though that could change based on how the regex changes. For example, if they take out the space split and start splitting on new lines only. That bug becomes messy because we're trying to guess to at the best way to clean up ugly input and no one set of rules will cover every scenario. And all the other scenarios in that bug are purely having to do with passing the barcode not it itself.

As far as actually documenting barcodes should we, in addition to saying "do not have spaces in the middle of your barcodes", also document best practices for barcodes? For example, I'd say a best practice is to limit barcodes to alphanumeric characters though that strictly isn't a requirement of Evergreen.

For example, currently '4444(333)4444' seems to work fine (based on a very brief test) but I could imagine someone using regex that doesn't escape special characters correctly and it breaking.

[Jane Sandberg (sandbergja)]

Good questions, Rogan. My preference is that we have a single list of barcode requirements, and not bother with best practices. That way, as long as both developers and libraries are adhering to the same list, we shouldn't run into issues like the one you describe. I don't really have a preference between a permissive or a strict list of requirements, as long as it isn't way too permissive or way too strict.

I'm also curious whether there are any screens or command-line tools that run into problems with non-ASCII characters in barcodes?

[Jeff Godin (jgodin)]

"Item barcodes should not contain spaces" and "do not have spaces in the middle of your barcodes" are opinions that I'd prefer not to see baked in to Evergreen.

Libraries do not always have control over some of the barcode strings that they may be required to handle.

Even if it were possible to normalize away the spaces without creating collisions, I'm not seeing justification for forbidding their use, which seems to be what this bug is proposing.