Screens are inconsistent when there is a space within the barcode of items or patrons

[Steve Callender]

Tested in 2.5 and 2.6

There is some inconsistency when dealing with spaces inside of barcodes.

For example, the registration allows you to use a space in the barcode, (My Barcode) and the F4 search will successfully find it if you search in the barcode field, but when doing a barcode search (F1) or putting in the barcode on the "Retrieve Patron" screen will not work. It looks like these two screens will trim the space out of the barcode causing the search to never be successful.

Item barcodes practically do the opposite. You can search for copies by barcode if they have a space in them (F5), but this moot since the system does not allow you to enter barcodes with spaces in them. In the item creator, it will automatically trim the space off when saving an item. This causes items that truly have spaces in them to fail when scanning in the barcode, since the item wasn't saved with the space.

So it looks like a determination needs to be made to either allow spaces in barcodes (across the board), or disallow them (across the board) because right now the screens behave in a mixed manner.

Steve

[Erica Rohlfs (erohlfs)]

Confirming this in Evergreen Version 2.9.

[Michele Morgan (mmorgan)]

I would be in favor of disallowing spaces in barcodes across the board and having all barcode input boxes, including the barcode search box in the opac, strip any spaces that may be entered.

If there are legitimate cases where patron or item barcodes must be recorded with spaces, I would like to see an option to disallow spaces across the board.

For evergreen installations that don't have a need to allow spaces in barcodes, the ability to disallow them entirely would avoid many headaches caused by inadvertently introducing a space when checking in items, or searching for items and patrons by barcode.

[Galen Charlton (gmc)]

There is at least one legacy system out there that includes interstitial spaces in barcode values (e.g., "T 123", "P 456", etc.). This is of course wrong and bad and terrible... but alas is a thing.

Consequently, while I would be in favor of a mode in Evergreen that strictly forbids spaces in barcodes and ignores them in barcode input widgets, I do not think it should be hardcoded.

[Blake GH (bmagic)]

Just FYI:
Newer versions of Evergreen remove ALL spaces within the patron barcode. See related bug 1692986. IRC Discussion:
http://irc.evergreen-ils.org/evergreen/2018-12-10#i_387641

[Rogan Hamby (rogan-hamby)]

As a note the update from 2018 is no longer accurate. Angular patron search does not remove included spaces.

[Rogan Hamby (rogan-hamby)]

currently for the staff client this is what I'm finding:

- patron search does not strip spaces
- checkout retrieve patron by barcode strips included space
- user permission does not strip included spaces
- angular item status does not strip out spaces
- item check in does not strip out spaces
- item check out does not strip spaces

So, thanks to the angular work the only thing I'm seeing right now is the patron retrieval in the checkout screen which this patches addresses:

user/rogan/lp1332651_consistent_barcode_spaces

99504184971c4f65b168eb8675c2c6f590d68a20

[Jason Etheridge (phasefx)]

I added a commit message and changed a tab to spaces and pushed this to master. Thanks!

[Jason Etheridge (phasefx)]

oops, same day, bug 1819367 added some whitespace stripping to Item Status, but was mirroring the whitespace stripping of the Upload File option for Item Status that we overlooked

[Jason Etheridge (phasefx)]

Pull Request for https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1332651-internal-space-followup

hopefully the Fix Committed status won't obscure this :)

[Galen Charlton (gmc)]

Tacking on new patches to a fix committed bug will obscure discoverability, at least for my workflow, which used canned LP queries that exclude fix-committed bugs. I'm see this only because saw the fix in the msater and wanted to check where it had been backported to.

[Galen Charlton (gmc)]

I'll sort this out.

[Galen Charlton (gmc)]

I ended up pushing a revert of Rogan's commit - not because of any problem with the patch itself, but because at the moment there's a bit more to the inconsistency that I think needs to be discussed first.

One issue is that OPAC login currently _always_ strips internal spaces per bug 1086064. That's a pretty big inconsistency, and means that staff interfaces that allow internal spaces in patron barcodes (which barcodes, per my comment #3, do exist) could allow registering patrons who cannot log in.

Another issue I ran across while testing this is that open-ils.search.multi_home.bib_ids.by_barcode doesn't remove any spaces at all, when it should at least remove leading and trailing whitespace.

Consequently, in the interests of fixing this once and for all, comprehensively, I suggest the following:

- all APIs that do patron or item barcode searches always strip leading and trailing whitespace
- all clients that collect patron and item barcodes for submission lookup APIs also strip leading and trailing whitespace
- item and patron retrieval by barcode, including for authentication, should get two bites at the apple: if internal spaces were supplied, first try to retrieve the record with spaces intact. If that fails, redo the search but without internal spaces.
- consider also allowing two bites at the apple for usernames when logging in
- add a library setting to specify whether internal spaces should be stripped upon saving a patron barcode to supplement ui.patron.edit.ac.barcode.regex
- add a library setting to specify whether internal spaces should be stripped upon saving an item barcode
- add a report to warn about cases where there's a collision between barcode values with and without spaces.

[Terran McCanna (tmccanna)]

+1 to Galen's suggested plan of attack in comment #12.

[Evergreen Bug Maintenance (bugmaster)]

Removing milestone targets because pullrequest tag was removed and bug is tagged needsdicussion.