web client: Duplicate barcode alert appearing on new barcodes

[Mary Jinglewski]

Within the web client, user is cataloging new items in the Volume/Copy Creator screen. As they scan in a brand-new barcode in the barcode field, the "duplicate barcode" alert appears below the barcode field. This occurs despite the barcode is being confirmed as never being used before in the consortium.

When the duplicate barcode alert appears in Evergreen, users *should* be unable to save these new items until a non-duplicate barcode is entered. In this bug, this expected behavior for the duplicate barcode alert does occur. The problem is that users are unable to save the item with the new barcode because this duplicate barcode alert appears.

So far the only way to "remove" the duplicate barcode alert is to either:
1) refresh the browser - and lose all the previously cataloged information - or
2) to close out the screen mid-cataloging (and lose all the previously cataloged information) and start the cataloging process over again from the bib record.

After re-starting via #1 or #2 above, it is confirmed that trying to catalog a new item again and re-entering the barcode, which caused the duplicate barcode alert, does not cause the alert to appear a second time.

Currently, there does not seem to be a pattern of when this duplicate barcode error appears in the web client. From previous reports, this apparently is not an issue in the XUL client.

This has been reported as being experienced by at least two Evergreen consortiums using v. 3.0, which includes up to v 3.0.7. This has been experience with the Chrome browser. Not confirmed if this issue also happens with Firefox.

Since a number of catalogers have reported this issue, this is likely a priority to be fixed. If other folks experiencing this bug would be so kind as to comment with their details, it would be greatly appreciated.

[Linnae Cintron (freedom452001)]

Hello,

Yes a few of us are experiencing this bug as well. I had been going back to XUL to finish cataloging an item when this duplicate barcode appeared. Then another co-worker said she would scan a completely different barcode which was accepted then re-scanned the original and the barcode then would be accepted. Of course this process slows us down but we don't lose work this way.

Linnae Cintron
Eastern Monroe Public Library
Stroudsburg, PA 18330
570-421-0800x312

[John Amundson (jamundson)]

We have had one report of this at CW MARS of which I am aware. I was under the working theory that the message comes from items incorrectly cataloged with partial barcodes.

For example,
If the barcode 37447123456 is getting the duplicate barcode message, there may be an item entered incorrectly as 3744712.

At our central site, we type in way more barcodes than we scan, and we see the duplicate barcode message as we are typing in the barcode digit by digit. By the time the entire barcode is typed, the message disappears. Possibly scanners enter digits too quickly to right the duplicate barcode message before the entire barcode is scanned. Again, just my working theory from our one report.

Staff said that they could simply delete the barcode and rescan it to get rid of the message.

Evergreen Web Client 3.0.8
Google Chrome

[Michelle Echols (mechols)]

Like John, when I encounter this issue I am usually able to fix it by clearing the barcode field, scanning a different unusued barcode, and then re-scanning the barcode I initially used. This allows you to continue on without closing or refreshing the page, but is still not ideal.

[Meg Stroup (mstroup)]

We are encountering this issue in multiple SCLENDS systems (Evergreen 3.1.5).

The primary workaround our catalogers are using is to delete the "duplicate" barcode and re-scan the barcode: it seems to work on the second try (and not flag as a duplicate, as it did on the first go-round). This is using the same barcode both times: we don't have to switch to a new barcode to clear the error.

It does not happen consistently, and we cannot identify a pattern. It's a significant workflow issue for the catalogers.

This issue has been reported consistently since we went live on 3.1 on September 26th.

[Andrea Neiman (aneiman)]

I'm not able to make this happen on 3.2.0, but I am typing in barcodes -- my hunch is that John is on to something with his theory that scanner entry is "too fast" and the erroneous duplicate barcode message gets stuck somehow.

Has anyone done extensive tests with typed vs scanned barcodes?

[Kathryn Riedener (kriedener)]

Our library staff is also encountering this issue. And all of the methods suggested above as work-arounds are being used.

[Meg Stroup (mstroup)]

I'm not sure if this qualifies as extensive testing (per Andrea's comment above), but I did some testing with typed vs scanned barcodes this morning. Evergreen 3.1.10, Chrome, Honeywell Fusion MS3780 scanner. The error appears randomly, so these results are not necessarily a hard and fast demonstration:

I got out my barcode deck and scanned 7 barcodes before hitting the duplicate barcode message [screenshot attached]. I then switched to hand-typing. By hand, I entered 114 barcodes and did not encounter the error message.

As John noted above, you will temporarily get the duplicate barcode message if you're hand-typing a barcode that is the same as your new barcode, up to a point [screenshot attached]. As you continue typing your new, non-duplicate barcode, the error message disappears.

[Meg Stroup (mstroup)]

Second image, as referenced above in #7.

The "too fast" theory continues to seem likely. I reiterate Mary's initial comment that this is a significant issue for catalogers. The workarounds do work, but, workflow-wise, this creates extra steps for catalogers.

[Linnae Cintron (freedom452001)]

I had forgotten I commented on this a year ago. After checking with my staff, everyone who catalogs is experiencing this issue. Initially people are concerned it's a scanner problem. This just slows up the workflow and then if we are trying to get a lot of work accomplished the tendency is to want to switch over to XUL. This happens whether we type in the barcodes or scan them.

[Linnae Cintron (freedom452001)]

A member of our staff found another workaround by backspacing one digit if the duplicate message appears and then retyping that one digit, then the barcode stays. This is a fast solution but again ideally we would rather not see this happen at all.

[John Amundson (jamundson)]

I was curious if anyone that has encountered this bug have tried the following:

1. Scan in a barcode that produces the "duplicate barcode" message. (This isn't guaranteed, so this is more of a try this when it happens type of approach).
2. As Linnae suggest, delete one digit and re-enter it so the message no longer appears.
3. Delete digits from the end of the barcode one at a time. At some point does the "duplicate barcode" message appear again?
4. When/If it does, take the partial barcode producing the message and throw it into Item Status. Chances are it's a mistyped barcode.
5. Confirm the item doesn't really exist and delete the item.
6. Repeat steps 3 through 5 until you're out of digits to delete.

Eventually, you'll remove all the incorrectly entered barcodes. And if the current theory holds that this is happening from entering the barcode "too quickly", you'll never see the duplicate barcode message again.

Because barcodes build on each other, the same incorrect barcode might be contributing to the message on many items, so this process might not take as long as you'd think.

This obviously isn't a full solution to the bug, but it will help with catalog/database cleanup.

[Elaine Hardy (ehardy)]

One of the reasons we created the Use checkdigit default is to prevent incorrectly scanned barcodes. The barcode scanners PINES had at the time often did not scan the barcode correctly and either left a partial barcode or one with extra characters.

If you have the default checked to use checkdigits, it should prevent incorrect scanning. However, I don't know if the default setting for it is locally configurable or not or if it is only Codabar. It also isn't a big help if you have multiple barcode formats.

[Elaine Hardy (ehardy)]

PINES is not seeing the duplicate barcode error, by the way. We are on 3.2

[Meg Stroup (mstroup)]

We continue to experience this issue on 3.1.11 (Chrome, and I'm using a Honeywell MS3780 scanner), in the production environment.

I am using sequential barcodes in these tests, since these seem most likely to cause the error to occur (eg ###420, ###421, ###422).

However, I ran the same tests I described in #7 (above) on a stock 3.1 server with the Concerto data and was unable to reproduce the error. I tested the 114 barcode set 3 times and a 40 barcode set once (in different sessions).

[Dan Briem (dbriem)]

The duplicate check runs on every change, so if you scan "123" (depending on how your scanner works) it typically sends 3 checks: "1","12","123". But, the checks are asynchronous, so they don't always finish in order. So, if "12" is in the system and you scan "123", if the "12" check happens to finish last, it will indicate it's a duplicate.

I can't say for certain this covers all of the experiences here, but I could only reproduce the error if I scanned a barcode (a bunch of times), there was a partial barcode already in the system, and the partial barcode check was the last one to resolve (3.3.2 test server).

This patch adds an incremented ID to each checkDuplicateBarcode promise and the callback function will only set the duplicate_barcode boolean if it's the latest promise sent. It's a challenge to test though, because the promises usually resolve in order.

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

[Mike Rylander (mrylander)]

Thanks, Dan. This is committed to 3.1 through master now.