Web client: precat item creation should be more intentional

[Chris Sharp]

PINES libraries are seeing problems with pre-cataloged items being created without full data entered. Symptoms are that the precat item has a non-standard (or garbage) barcode with the correct barcode entered as the precat title. Our working theory on this is that staff scan something that creates the bad barcode, followed by a newline ("Enter") character, which opens the precat creation modal, followed by a correct scan of the barcode, followed by a newline character, which then closes the modal. The result is a mis-scanned item that should not have been checked out as a precat and all the ensuing confusion that results from an item being on the shelf and checked out at the same time.

The XUL client did not suffer this problem, because rather than going straight to the pre-cat window, it popped up a warning box that allowed staff to either cancel out and try re-scanning the barcode, or to create a pre-cat. Either way, the process was more intentional, and we need something similar in the web client.

Evergreen 3.0.X
OpenSRF 3.0.X
Ubuntu 16.04 LTS
PostgreSQL 9.5

[Michele Morgan (mmorgan)]

Tested this on a 3.0.7 system and I would say that fixing these two issues would go a long way toward minimizing unintended precats.

1. Add a confirmation screen like the xul client has, that the scanned barcode is not cataloged.

2. Prevent submission of the precat modal form with an "Enter". Currently, as long as there is something in the Title field, an "Enter" will submit the precat creation form.

Also, just wanted to add a note that checkin the "Strict barcode" checkbox on the checkout screen in the web client will add another speed bump to precat creation by informing the staff user that the barcode is invalid.

[Elaine Hardy (ehardy)]

Unfortunately, checking the strict barcode box is not as viable a solution to incorrect scanning as we thought it would be at the time we developed it. Many PINES libraries have a combination of item barcodes with the codabar encoding and older items that are not codabar. Even if the checkout library has all codabar barcodes, items from other libraries may not. Checking the strict barcode box means check out (or in) of those non-codabar barcodes is stopped. Circ staff generally do not check that box because of this, losing the speed bump.

[John Amundson (jamundson)]

We are also seeing this in CW MARS. We recently had a report from a library who uses an RFID scanning pad.

There are some items in our system that begin with the letter "A", always capitalized. If caps lock is on on the computer and the item is scanned by the RFID pad, a precat checkout screen comes up. If the item gets too close to the pad at all, the precat record is checked out with the item's barcode, (now with a little "a"), as the title and barcode.

I also vote to have the warning/confirmation screen come back from the xul client.

See related bug: https://bugs.launchpad.net/evergreen/+bug/1622364

[Dan Briem (dbriem)]

Here's a branch for testing. https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbriem/lp1778522_intentional_precat_creation

This patch came out of the 11/18/20 New Developer's Working Group meeting. This approach doesn't include an extra confirmation dialog because the form requires an intentional interaction with a button and can be canceled using the existing interface.

[Terran McCanna (tmccanna)]

I think this works well and my signoff is here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1778522_intentional_precat_creation_signoff

I agree that requiring an intentional interaction on the button works well to prevent the accidental creation of precats that we are seeing a problem with in PINES.

[Bill Erickson (berick)]

Issue and fix confirmed. Merged to 3.5 and up. Thanks, all!