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.
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 edit.ac. barcode. regex
- 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.
- 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.