No error message when using duplicate barcodes in Serials Batch receive interface

Bug #1081551 reported by Eva Cerninakova on 2012-11-21
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Usually when duplicate barcode is used adding new item in Evergreen (e.g.. in Holding maintenance interface), we get an error message.
But when we accidentally used duplicate barcodes for serial items in Serials Batch receive interface (we barcode each serial item individually) no error message appeared and we discovered the problem of coliding barcodes when checking out serial item in question,
 see http://knihovna.jabok.cz/Evergreen/bugs/duplicate_barcode.jpg
I think there should be error message in Evergreen for using duplicate barcode in Serials batch receive interface too.
We use Evergreen version 2.2

Eva Cerninakova (ece) on 2012-11-21
description: updated
Changed in evergreen:
status: New → Triaged

Hello Eva.

This bug has been reported at other sites, too. A technical note follows to guide the development of a future patch.

serial.unit is a child table of asset.copy. Each table has a unique constraint for the "barcode" field (when the "deleted" field is false, anyway). These constraints do not prevent the duplicates between two rows if one row is only in asset.copy and the other is in serial.unit, due to a PostgreSQL limitation that I didn't appreciate when I wrote the serials batch receive code.

The "safest" fix, from the point of view of providing the best guarantee of future data integrity, may be a trigger on INSERT or UPDATE operations to serial.unit that tests for the presence of the incoming barcode explicitly, and raises an exception when found.

Thanks for information :-)
Eva

On 7 March 2013 23:04, Lebbeous Fogle-Weekley
<email address hidden> wrote:
> Hello Eva.
>
> This bug has been reported at other sites, too. A technical note
> follows to guide the development of a future patch.
>
> serial.unit is a child table of asset.copy. Each table has a unique
> constraint for the "barcode" field (when the "deleted" field is false,
> anyway). These constraints do not prevent the duplicates between two
> rows if one row is only in asset.copy and the other is in serial.unit,
> due to a PostgreSQL limitation that I didn't appreciate when I wrote the
> serials batch receive code.
>
> The "safest" fix, from the point of view of providing the best guarantee
> of future data integrity, may be a trigger on INSERT or UPDATE
> operations to serial.unit that tests for the presence of the incoming
> barcode explicitly, and raises an exception when found.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1081551
>
> Title:
> No error message when using duplicate barcodes in Serials Batch
> receive interface
>
> Status in Evergreen - Open ILS:
> Triaged
>
> Bug description:
> Usually when duplicate barcode is used adding new item in Evergreen (e.g.. in Holding maintenance interface), we get an error message.
> But when we accidentally used duplicate barcodes for serial items in Serials Batch receive interface (we barcode each serial item individually) no error message appeared and we discovered the problem of coliding barcodes when checking out serial item in question,
> see http://knihovna.jabok.cz/Evergreen/bugs/duplicate_barcode.jpg
> I think there should be error message in Evergreen for using duplicate barcode in Serials batch receive interface too.
> We use Evergreen version 2.2
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1081551/+subscriptions

Bill Erickson (berick) wrote :

User-facing fixes pushed to:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1081551-dupe-serial-item-barcode

This includes a check within the serials receive API call to detect and alert on duplicate barcodes and code in the batch receive UI to detect this event and warn the user.

Since these two bits of code are needed to provide any semblance of a meaningful message to the user (instead of DATABASE_UPDATE_FAILED) and they resolve the issue at hand, I have opted not to add the additional DB check within this patch. It would still be a good thing to have, though.

Changed in evergreen:
milestone: none → 2.6.1
tags: added: pullrequest serials
Changed in evergreen:
status: Triaged → Confirmed
Changed in evergreen:
milestone: 2.6.1 → 2.6.2
Changed in evergreen:
assignee: nobody → Jennifer Pringle (jpringle-u)
Jennifer Pringle (jpringle-u) wrote :

It is still possible to use an existing item barcode for a serial item if you do the following:

1. Find the item in the catalogue
2. Actions for this Record -> Holdings Maintenance
3. Select the item and click on Actions for Selected Rows -> Replace Barcode
4. Enter duplicate barcode and click Re-barcode / Update Items. Item is saved with duplicate barcode without any warning or error message.

The desired error message "Another copy has barcode "CONC40000558", defaulting to system-generated." appears if you attempt to use a duplicate barcode with a serials item in the following places:
- Serial Control View -> Items -> Receive/Move Selected
- Serials Batch Receive
- Item Status -> Actions for Cataloguers -> Replace Barcode
- Item Status -> Actions for Selected Items -> Replace Barcode

Changed in evergreen:
assignee: Jennifer Pringle (jpringle-u) → nobody
Jennifer Pringle (jpringle-u) wrote :

Technically the issue of being able to use duplicate barcodes with serial items through Replace Barcode in Holdings Maitenance could be considered a separate bug from the issue of being able to use duplicate barcode with serial items Serials Batch Receive.

The Serials Batch Receive is fixed. Should I create a new bug report for Replace Barcode in Holdings Maitentance? My preference would be to bundle a fix for that with the fix or the Batch Receive so it is no longer possible to use duplicate barcode with the serials module anywhere once the fix is applied.

Kathy Lussier (klussier) wrote :

Jennifer,

I would recommend signing off on this bug and then reporting a new bug for holdings maintenance issue. I think getting a partial solution into the system is probably better than waiting for the full solution.

Kathy

Jennifer Pringle (jpringle-u) wrote :

I have tested this code (against master) and consent to signing off on it with my email address, [<email address hidden>], and name, [Jennifer Pringle].

tags: added: signedoff
Jennifer Pringle (jpringle-u) wrote :

Holdings Maintenance issue reported as https://bugs.launchpad.net/evergreen/+bug/1362743

Galen Charlton (gmc) on 2014-09-09
Changed in evergreen:
milestone: 2.6.3 → 2.6.4
Ben Shum (bshum) wrote :

Picked to master. Not sure about 2.5 and 2.6 due to new strings?

Changed in evergreen:
milestone: 2.6.4 → 2.7.0-rc
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released

While testing bug 1414197, I noticed this is fixed in Evergreen version 2.8

Confirm you now get an error "Rename aborted. Another copy has barcode "34028"" when I try to rebarcode a copy with a barcode that is already in use.

no longer affects: evergreen/2.6
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers