Can Add Copies to Bibs with Source that Does Not Allow Copies

Bug #1805663 reported by Jason Stephenson
This bug affects 6 people
Affects Status Importance Assigned to Milestone

Bug Description

The XUL Client had code to prevent adding copies to bib records on a bib source with the can_have_copies field set to false. The web staff client appears to lack this code, and staff are able to add copies to volumes on these bibs.

These kinds of bib sources can be used for electronic resource records, and the field was introduced with bug 869338.

Tags: cataloging
tags: added: webstaffclient
Revision history for this message
Mary Llewellyn (mllewell) wrote :

I just verified that volumes/copies can be added to our digital subscription records whose source is set with can_have_copies field set to false. Web client version 3.1.8.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Anna Goben (agoben) wrote :

Confirming this is also an issue in 3.2.1

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Revision history for this message
Jason Stephenson (jstephenson) wrote :

It's possible to add copies to bibs on sources with the can_have_copies flag set to false in the following ways:

1. Directly in the database via SQL inserts.
2. Via acquisitions if acq picks a bib on one of these sources.
3. Via Vandelay, if we're matching bibs on import.
4. Directly via the web staff client.

This raises the question of at what level do we want to add the protection against adding copies and volumes to these bibs? Adding a trigger in the database would be the most comprehensive protection, but the other subsystems will need to deal with it. Barring the addition of a trigger in the database, that leaves #1 still possible, but that is also the least likely way for copies to be created. However, that still leaves the other subsystems requiring modifications to honor the can_have_copies flag on the bib source. This could go in two directions. Each subsystem could be modified separately to handle the can_have_copies flag, or a common bit of code could be added to the back end that prevents the addition, i.e. throwing an error, and then each subsystem is modified separately to handle it.

Beyond the question of where to implement the check, there is also the question of user interface. That is, how is the user going to be presented with the notice of failure to create the copies, and how is the user going to be able to recover from that failure?

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
tags: added: cataloging
no longer affects: evergreen/3.1
tags: removed: webstaffclient
no longer affects: evergreen/3.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.