web client: Duplicate barcode alert appearing on new barcodes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.1 |
Fix Released
|
Medium
|
Unassigned | ||
3.2 |
Fix Released
|
Medium
|
Unassigned | ||
3.3 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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.
Changed in evergreen: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in evergreen: | |
milestone: | none → 3.3.4 |
Changed in evergreen: | |
milestone: | 3.3.4 → 3.3.5 |
Changed in evergreen: | |
status: | Confirmed → Fix Committed |
Changed in evergreen: | |
status: | Fix Committed → Confirmed |
Changed in evergreen: | |
status: | Confirmed → Fix Committed |
Changed in evergreen: | |
milestone: | 3.3.5 → 3.4.1 |
status: | Fix Committed → Fix Released |
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