Web Client - When adding vols/copies to multiple branches, circ library does not populate

Bug #1732761 reported by Elaine Hardy on 2017-11-16
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

Bug Description

When simultaneously adding vols/copies to multiple branches/libraries, circulating library does not propagate from the owning library (or is populated by workstation OU.

When adding multiple vols and copies from Add volume button on record holdings view and then adding additional libraries volumes, the circulating library in the item attributes editor is (unset). In order to save copies, must choose one library. This means the wrong circulating library is assigned for most branches and must be edited to owning library for each branch individually.

When adding copies to multiple libraries by choosing them from the Holdings view, the circulating library in item attributes is the workstation OU (this may be related to https://bugs.launchpad.net/evergreen/+bug/1675882). Again, after adding copies, circ library must be edited to the correct OU.

In the XUL client, the owning library is automatically propagated to the circ library for the copies, whether adding vols and copies or just copies across multiple libraries/branches.
PINES has library systems with more than 10 branches (one with 19). This bug would seriously impact workflows to the point that large systems would be unable to implement the web client for cataloging.

Elaine Hardy (ehardy) wrote :

Further testing shows that when adding new vol/copies, as long as the circ library remains unset in the item attribute area, the circ library is populated by the owning library. However, if you are adding copies to existing vols/copies across multiple libraries, the circ library, even if a template is used with circ library <unset>, is not populated from the owning library for the new copies.

Chris Sharp (chrissharp123) wrote :

I thought it would be useful to show screenshots of the behavior when adding copies across libraries to existing volumes. The XUL client screenshot shows the expected behavior - it shows each of the circulation libraries for each copy. The web client just selects one of the two (seen in the web client screenshot). Not sure at this point what the solution is.

Chris Sharp (chrissharp123) wrote :
Chris Sharp (chrissharp123) wrote :
Changed in evergreen:
status: New → Confirmed
Andrea Neiman (aneiman) on 2017-12-19
tags: added: webstaffclient
Dan Wells (dbw2) on 2018-03-29
Changed in evergreen:
importance: Undecided → High
Andrea Neiman (aneiman) on 2018-04-24
tags: added: ca
tags: added: cataloging
removed: ca
Jason Etheridge (phasefx) wrote :

"In order to save copies, must choose one library."

I'm not sure this is true. Here's one workflow I tried with stock concerto:

* retrieve record id 1
* Click the "Add Volumes" button (to left of the Serials menu)

A new tab should open with the Volume/Copy Editor, and we should have one new volume and item pre-populated.

The Circulation Library should show BR1 for the item.

* In the org selector to the left of that interface's "Add volume" button, set the menu to BR2
* Click the "Add volume" button.

We should now have a BR1 volume and BR2 volume, each with 1 copy.

The Circulation Library should show Unset for both items. If you select just one of the items in the Working Copies pane, then you should see either BR1 or BR2 depending on the item selected. If you re-select both items, it should change to Unset again.

So the interface is showing (Unset) in lieu of showing a summarized breakdown of active values as it does in the XUL client. I think this is an area that could use enhancement, but continuing on...

* Add a barcode to the item for the BR1 volume
* Add a call number to the BR2 volume and barcode to its item
* click Save & Exit

The two items should have different circ lib values, matching their volume owning libs.

Are you seeing different?

However, in Holdings View, when I select two items with different owning libs, and then do Actions -> Add: Copies, I get the two different volumes with two different items, but the circ lib for both are the same and have no relation to the owning lib (I get BR1 even if I select a BR2 and BR3 item). Actions -> Add: Volumes and Copies does almost the same thing, but I get the expected Unset with both working copies selected. I wonder if the intention was for Add: Copies to hide the volume editing section of the interface. One thing it does right that Volumes and Copies doesn't is set the correct call number classification for the selected volumes. :-/

Mike Rylander (mrylander) wrote :

The primary bug here, AFAICT, is that multiple values on any given field are not represented in a way similar to the XUL interface, where you could inspect the set of values in use. Here is a branch that provides that functionality:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1732761-item-multi-value-edit

From the commit message:

Previous to this commit, the display of multiple different values for a field in the item attribute editor was simply to display no value. Here we add a UI component that presents the list of unique values, the number of selected copies that use each value, and the ability to select just those copies using a particular value by clicking on the desired value.

tags: added: pullrequest
Elaine Hardy (ehardy) wrote :

I'm sorry I missed Jason's response -- PINES catalogers have reported, and I have confirmed, that this is inconsistent. Sometimes the correct circ library does not propagate and sometimes it does. Sometimes applying templates works when the circ library is unset, and all attributes are applied correctly, including circ library. Sometimes the same template fails when trying to apply it. When the template fails, we can't save and exit OR we can save and exit but all items have the workstation OU circ library.(This depends on whether the template fails totally, and applies none of the saved attributes, or if it applies some of the attributes, but doesn't handle the circ library correctly) When the template fails, it never applies correctly again, in our experience

Most reliable is to manually edit the item attributes, leaving the circ library unset. While that does occasionally fail and either you can't save and exit or the circ library doesn't propagate correctly, it is more reliable than using templates.

The templates that fail are both those created in the XUL client and those created in the web client. Some libraries have never had a template fail.

I will get with Chris and see how best we can test the branch, Mike.

Mike Rylander (mrylander) wrote :

I've put this up on the cataloging bug-fix test server at https://dev-bugsquash.equinoxinitiative.org/eg/staff/

Andrea Neiman (aneiman) wrote :

This is available for testing at https://dev-bugsquash.equinoxinitiative.org/eg/staff/ for anyone who wants to take a look at it.

Mike Rylander (mrylander) wrote :

I think the commit at the very top of the current omnibus branch, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1773417-omnibus-holdings-rebase-squash , will address one of the situations, where adding copies to existing call numbers would not use the call number owning lib as the copy home lib. This commit is now loaded on the test server mentioned above, as well. A hard browser refresh may be warranted to get the new code.

Bill Erickson (berick) wrote :

As discussed in IRC, the fix for this bug was included in the omnibus branch, which has now been merged. Marking as duplicate.

Kathy Lussier (klussier) wrote :

Actually, this fix was merged as part of bug 1738890, not the Omnibus branch. Correcting the duplicate status now.

Dan Wells (dbw2) wrote :

Thank you for clearing any confusion, Kathy!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers