Adding the same new part to more than one item can cause part creation to fail

Bug #2007284 reported by Jason Boyer
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned
3.10
Confirmed
Undecided
Unassigned
3.11
Confirmed
Undecided
Unassigned
3.9
Won't Fix
Undecided
Unassigned

Bug Description

Evergreen 3.9+

When adding parts to existing items you may want to add the same part to multiple items at once. This works fine so long as the part already exists, but if you're creating the part new your holdings editor tab will stop responding as it fails to handle an INSERT error caused by trying to create the same part a second time.

Example:
Open bib 2 in a Concerto dataset
Edit the call number at a location with multiple copies
Add the same new part name to 2 items
Click apply all and Save
The progress bar never stops bouncing and the parts are not created.

The backend batch process that creates the new parts should be updated to check new part names against each other as they're being created.

Jason Boyer (jboyer)
Changed in evergreen:
milestone: none → 3.next
no longer affects: evergreen/3.11
Elaine Hardy (ehardy)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Jason Boyer (jboyer) wrote :

And here's a branch that lets you add the same new part(s) to as many items as you can stand:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp2007284_parts_parts_parts / working/user/jboyer/lp2007284_parts_parts_parts

tags: added: pullrequest
tags: added: cataloging
Revision history for this message
Beth Willis (willis-a) wrote :

I tested this fix on Tiffany's server as follows:

---I created two items attached the same call number
--I saved the items without attempting to add parts

--I edited the above two items
--I created a new partfor the first item
--I then created the same part for the second item
--I saved and exited

The parts were not saved

I am not sure if the initial bug reported also applied to adding parts when creating, rather than editing, items. I tested this and got the same results; the parts did not save.

I used both the "Edit Call Numbers" and "Edit Call Numbers and Items" options with no difference in outcome.

Adding the same newly created part to multiple items is not something I have ever needed to do, so perhaps I have misunderstood this bug report. If so, clarification would be appreciated.

Revision history for this message
Elaine Hardy (ehardy) wrote :
Download full text (3.7 KiB)

Tested on https://tiffany-master.gapines.org/eg2/en-US/staff/

1) When I create multiple different part labels within the holdings editor that have not been created under the monographic parts tab, creation is succesfull (Vol. 1, Vol. 2, Vol.3, etc.)

2) However, when I attempt to create multiple instances of the same part in the holdings editor (Vol. 1) it silently fails.

3) When I have some parts created and need to add others, each different, as I edit in the holdings editor, I am able to do that

4) If I have some parts created, and one that is not, I can add one instance, but not multiple. Holdings editor doesn't close and continues to spin

Console messages for #4

Failed to load resource: the server responded with a status of 404 ()
net.service.ts:144 open-ils.cat.asset.volume.fleshed.batch.update failed! stat=500 msg= *** Call to [open-ils.cat.asset.volume.fleshed.batch.update] failed for session [0.50957755446404931677613720274], thread trace [0]:
Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.26.1/OpenILS/Utils/CStoreEditor.pm line 616.

onmethoderror @ net.service.ts:144
core.js:6498 ERROR Error: Uncaught (in promise): open-ils.cat.asset.volume.fleshed.batch.update failed! stat=500 msg= *** Call to [open-ils.cat.asset.volume.fleshed.batch.update] failed for session [0.50957755446404931677613720274], thread trace [0]:
Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.26.1/OpenILS/Utils/CStoreEditor.pm line 616.

    at resolvePromise (zone.js:1211:1)
    at resolvePromise (zone.js:1165:1)
    at zone.js:1278:1
    at _ZoneDelegate.invokeTask (zone.js:406:1)
    at Object.onInvokeTask (core.js:28679:1)
    at _ZoneDelegate.invokeTask (zone.js:405:1)
    at Zone.runTask (zone.js:178:1)
    at drainMicroTaskQueue (zone.js:585:1)
    at ZoneTask.invokeTask [as invoke] (zone.js:491:1)
    at invokeTask (zone.js:1648:1)
defaultErrorLogger @ core.js:6498
DevTools failed to load source map: Could not load content for chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/browser-polyfill.js.map: System error: net::ERR_FILE_NOT_FOUND

Console message for #2

net.service.ts:144 open-ils.cat.asset.volume.fleshed.batch.update failed! stat=500 msg= *** Call to [open-ils.cat.asset.volume.fleshed.batch.update] failed for session [0.14838043856953111677613975224], thread trace [0]:
Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.26.1/OpenILS/Utils/CStoreEditor.pm line 616.

onmethoderror @ net.service.ts:144
OpenSRF.Stack.handle_message @ opensrf.js:731
OpenSRF.Stack.push @ opensrf.js:693
OpenSRF.websocketConnection.onmessage @ opensrf.js:388
socket.onmessage @ opensrf_ws.js:78
wrapFn @ zone.js:766
invokeTask @ zone.js:406
onInvokeTask @ core.js:28679
invokeTask @ zone.js:405
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1648
globalCallback @ zone.js:1679
globalZoneAwareCallback @ zone.js:1712
core.js:6498 ERROR Error: Uncaught (in promise): open-ils.cat.asset.volume.fleshed.batch.update failed! stat=500 msg= *** Call to [open-ils.cat.asset.volume.fleshed.batch.update] failed for session [0.14838043856953111677613975224], thread trac...

Read more...

Revision history for this message
Jason Boyer (jboyer) wrote :

These errors sound like the changes aren't taking effect. Since it's a perl change OpenSRF services have to be restarted after applying this patch. Since I accidentally left in a 'use Data::Dumper;' from debugging I've cleaned that up and rebased the branch to the latest master.

Revision history for this message
Mary Llewellyn (mllewell) wrote :

Tested on https://butternut.evergreencatalog.com.

Added 2 items with a new part label of v. 1. Worked as expected, resulting items had the part label. Looked in Monographic Parts and saw one entry for the new part.

I have tested this code and consent to signing off on it with my name, Mary Llewellyn and my email address, <email address hidden>.

Changed in evergreen:
assignee: nobody → Mary Llewellyn (mllewell)
tags: added: signedoff
Changed in evergreen:
assignee: Mary Llewellyn (mllewell) → nobody
Revision history for this message
Elaine Hardy (ehardy) wrote :

Noting that this works only when items edited are attached to the same library and the same call number. It failed when I chose multiple call numbers in the same library and across branches with console error (in Firefox)

Unknown property ‘-moz-border-radius’. Declaration dropped. codemirror.css:244:22
Error in parsing value for ‘direction’. Declaration dropped. alert.xhtml
Some cookies are misusing the recommended “SameSite“ attribute 8
Some cookies are misusing the recommended “SameSite“ attribute 4
Error in parsing value for ‘direction’. Declaration dropped.

Revision history for this message
Terran McCanna (tmccanna) wrote :

Removing signoff as per comment #6

tags: removed: signedoff
Revision history for this message
Jason Boyer (jboyer) wrote :

Oh, thanks Elaine, I forgot to test that use case. I'm confident that can be fixed too but will take a little more tweaking.

tags: added: needswork
removed: pullrequest
tags: added: cat-parts
Changed in evergreen:
milestone: 3.next → 3.12-beta
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.