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

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.

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.

"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. :-/

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.

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.

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

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

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.

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

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

Thank you for clearing any confusion, Kathy!