Evergreen

Shelving locations in holdings editor only workstation library

Bug #1956626 reported by Elaine Hardy on 2022-01-06

This bug affects 14 people

Affects		Status	Importance	Assigned to	Milestone
	Evergreen	Fix Released	High	Unassigned	Evergreen 3.9-rc
	3.8	Fix Released	High	Unassigned	Evergreen 3.8.1

Bug Description

For 3.8 -- high level bug

When multiple libraries chosen for holdings editing or adding, shelving locations in the dropdown in the holdings editor are only those owned by the workstation library.

Workflow:

Logged in with a STATELIB-L workstation
Chose STATELIB-L, STATELIB-B, STATELIB-L to add call numbers and items
Click on dropdown menu for shelving locations in holdings editor. Only STATELIB-L and PINES owned shelving locations display

In 3.6 and before, shelving locations for all libraries chosen for editing or adding items and call numbers display

Logged in with a STATELIB-L workstation
Chose STATELIB-L, STATELIB-B, STATELIB-L to add call numbers and items
Click on dropdown menu for shelving locations. All shelving locations owned by those libraries and owned by PINES display (Locations for other branches do not display)

Since PINES libraries catalog at the system level, all shelving locations owned by each library/branch need to display.

We had the same issue when we migrated to the webclient -- https://bugs.launchpad.net/evergreen/+bug/1739460

See attachment with screen shots

Tags:

Revision history for this message

Elaine Hardy (ehardy) wrote on 2022-01-06:

Shelving locations in holdings editor only workstation library.docx Edit (116.6 KiB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Terran McCanna (tmccanna) on 2022-01-06

Changed in evergreen:
importance:	Undecided → High

Revision history for this message

Kate Coleman (katecoleman) wrote on 2022-01-10:

+1 This is a crucial issue for us in Missouri Evergreen as well.

Jennifer Pringle (jpringle-u) on 2022-02-14

Changed in evergreen:
status:	New → Confirmed

Revision history for this message

Bill Erickson (berick) wrote on 2022-04-19:

Here's a fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1956626-volcopy-more-copy-locs

Changed in evergreen:
assignee:	nobody → Bill Erickson (berick)
milestone:	none → 3.9-rc
tags:	added: pullrequest
Changed in evergreen:
assignee:	Bill Erickson (berick) → nobody

Revision history for this message

Jane Sandberg (sandbergja) wrote on 2022-04-20:

Works well for me! Thanks, Bill! Pushed to 3.8 and above.

Changed in evergreen:
status:	Confirmed → Fix Committed
tags:	added: signedoff

Revision history for this message

Elaine Hardy (ehardy) wrote on 2022-04-20:

I also tested this and it works for me as well.

Thanks Bill!!

Revision history for this message

Elaine Hardy (ehardy) wrote on 2022-04-20:

I spoke to soon. While the shelving locations display in the editor, holdings are not saving when I add holdings -- the holdings editor spins and hangs.

If I edit an item, I can change the shelving location in a nonworkstation org unit.

Revision history for this message

Elaine Hardy (ehardy) wrote on 2022-04-20:

And it looks like it isn't saving to workstation library either.... Sorry for the confusion.

Console error message:

main.83e1c293da137dcd2dd9.js:1 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.97951123935590621650462834107], thread trace [0]:
Can't call method "isnew" on unblessed reference at /usr/local/share/perl/5.26.1/OpenILS/Application/Cat/AssetCommon.pm line 272.

onmethoderror @ main.83e1c293da137dcd2dd9.js:1
main.83e1c293da137dcd2dd9.js:1 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.97951123935590621650462834107], thread trace [0]:
Can't call method "isnew" on unblessed reference at /usr/local/share/perl/5.26.1/OpenILS/Application/Cat/AssetCommon.pm line 272.

    at T (polyfills.9b26e9b6c6d2049cc2b1.js:1:12874)
    at T (polyfills.9b26e9b6c6d2049cc2b1.js:1:12402)
    at polyfills.9b26e9b6c6d2049cc2b1.js:1:13683
    at l.invokeTask (polyfills.9b26e9b6c6d2049cc2b1.js:1:7920)
    at Object.onInvokeTask (main.83e1c293da137dcd2dd9.js:1:379346)
    at l.invokeTask (polyfills.9b26e9b6c6d2049cc2b1.js:1:7841)
    at i.runTask (polyfills.9b26e9b6c6d2049cc2b1.js:1:3329)
    at m (polyfills.9b26e9b6c6d2049cc2b1.js:1:9914)
    at u.invokeTask [as invoke] (polyfills.9b26e9b6c6d2049cc2b1.js:1:8999)
    at p (polyfills.9b26e9b6c6d2049cc2b1.js:1:21253)
On @ main.83e1c293da137dcd2dd9.js:1

Revision history for this message

Bill Erickson (berick) wrote on 2022-04-20:

Elaine, the error posted appears to be related to copy alerts. Are you by chance also modifying copy alerts? If I recall, there is another LP about that one.

Revision history for this message

Elaine Hardy (ehardy) wrote on 2022-04-20:

Sigh. I used a template that normally doesn't have an alert but I had added an alert to it when I was testing that. I created a template that didn't have alerts and it does save.

Sorry for ALL the confusion. Sometimes there isn't enough caffeine in the world.

FYI -- I thought I had also opened a bug report about the same issue with creating holdings templates in Local admin. I don't find it so will open one when I can.

Evergreen Bug Maintenance (bugmaster) on 2022-05-05