Web Client : Show empty volumes Holdings view

Bug #1715697 reported by Elaine Hardy on 2017-09-07
This bug affects 14 people
Affects Status Importance Assigned to Milestone

Bug Description

When in Holdings view for a record, checking Show empty volumes does not display empty volumes. Displaying empty volumes can be helpful in transferring volumes and in adding vols/copies. Currently, adding vols by changing the owning library is a few more steps. Displaying libraries with empty volumes would streamline workflow of both transferring and adding vols.

Elaine Hardy (ehardy) wrote :

This is for ver 2.12

tji@sitka.bclibraries.ca (tji) wrote :

It works for me on 3.0.

Tina Ji

tji@sitka.bclibraries.ca (tji) wrote :
Elaine Hardy (ehardy) wrote :

Is is still not for PINES. We have 3.0.1. In the attached screenshots, the library ARCPLS, has 2 other branches with no copies. Only the four with copies display.

If a library has no copies in their branches, no items display

Blake GH (bmagic) wrote :

It may not be technically a bug. I think I see what is going on here. Instead of listing off every branch - it just lists those that have something on that bib. It reduces the clutter. If you want a branch to show up, then you need to add a volume to it. Then you will see it (if you have show empty volumes turned on) - then another layer of confusion comes in. Where both the volume AND the copy are manifested together on the same row. When you right click that row, you get both options for the copy AND the volume.

Elaine Hardy (ehardy) wrote :

You can't add empty vols in the web client see https://bugs.launchpad.net/evergreen/+bug/1732201

Blake GH (bmagic) wrote :


I think that is the bug. This bug probably needs to be merged.

In the XUL client, you can see libraries with no vols/copies attached in
holdings maintenance. It makes adding vols and copies much easier

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128 Office
404.548.4241 Cell
404.235.7201 FAX

On Tue, Dec 12, 2017 at 2:58 PM, Blake GH <email address hidden>

> Elaine,
> I think that is the bug. This bug probably needs to be merged.
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1715697
> Title:
> Web Client : Show empty volumes Holdings view
> Status in Evergreen:
> New
> Bug description:
> When in Holdings view for a record, checking Show empty volumes does
> not display empty volumes. Displaying empty volumes can be helpful in
> transferring volumes and in adding vols/copies. Currently, adding vols
> by changing the owning library is a few more steps. Displaying
> libraries with empty volumes would streamline workflow of both
> transferring and adding vols.
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1715697/+subscriptions

Kate Coleman (katecoleman) wrote :


It absolutely makes adding vols and copies much easier. If you are a library with multiple branches, not having this option makes workflow much longer.

Kathy Lussier (klussier) wrote :

I'm just catching up on this bug and want to make sure I'm understanding it correctly.

When I toggle the show empty volumes option, it controls whether or not I can view volumes that do not yet have copies. In that context, I agree with Blake that this is working as intended by the developers.

But what I think I'm hearing is that we want a way to show the libraries that have no volumes or copies, similar to the 'hide empty libs' option we used in the xul client. Is that correct?

One of many use cases for this would be for libraries that perform centralized cataloging for all of their branches. In the xul client, you could select the libraries that are receiving the copy, and add the volumes/copies for those libraries. In the web client, the only way you could follow this workflow is if the receiving library is one that already owns the title. If it doesn't already own the title, they don't display in holdings view.

There is a workaround where you can now designate these libraries in the copy/volume editor, but Elaine is reporting that it takes more steps using this workaround.I don't think this is a duplicate of bug 1732201. More work would be required to make 1732201, and this functionality needs to be addressed with or without the empty volume issue being resolved.

I had two thoughts on this:

- Add an option to show empty libraries, which is similar to the way we handled this issue in the xul client.
- Replace the show empty volumes option with the empty libraries option. Is there any benefit to having that empty volumes option? Can we address any issues by just having the one 'show empty libraries' option?

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Elaine Hardy (ehardy) wrote :

Empty libraries is what we need in holdings view so it is analogous to the XUL client. PINES libraries do centralized cataloging and having the option to choose the libraries at this point streamlines workflows.

I would prefer that the current Show empty vol button be replaced with Show empty libs, empty vols should display in holdings view when present without any extra step..(We also need the ability to add empty vols as in bug 1732201).

Deborah Luchenbill (deborah) wrote :

Like PINES, Missouri Evergreen needs empty libraries, as well. I think either of Kathy's options is fine but also agree with Elaine that empty volumes displaying without any extra step would be good.

Blake GH (bmagic) on 2018-01-11
tags: added: webstaffclient
Mary Llewellyn (mllewell) wrote :

Coming in late, but Bibliomation also needs to see empty libraries in the Holdings View.

Kathy Lussier (klussier) on 2018-03-29
Changed in evergreen:
importance: Medium → High
Janet Schrader (jschrader) wrote :

Coming in even later, this bug affects CWMARS as we have two city libraries with multiple branches as well as several smaller ones with 2-3 branches.

Showing empty libraries in holdings view would also help with transferring items from one bib record to another.

There was a comment that selecting the branches in the copy/volume editor put them in the order added so if you added one later the branches weren't in order. Using 3.0 I added volumes for branches in random order and EG put them in alphabetical order.

Scott Thomas (scott-thomas-9) wrote :

This bug is a serious problem for PaILS.

Kathy Lussier (klussier) wrote :

Adding a link to list discussion on this bug.


Scott Thomas (scott-thomas-9) wrote :

Here is a first pass on how we think this should work:

1. Library / Barcode, Volumes, and Copies columns should be added to the grid. Under Library / Barcode, the grid should display all org units that reside at or below the org unit selected in "Show holdings at or below." They should display even if they have no volumes or copies. (See questions below.)The Volumes and Copies columns will display the number of said items.

2. For empty libraries, selecting one of the lines on the grid will allow you to invoke "Add Volumes / Copies" via right-click or the Actions dropdown. You will have more options with populated libraries.

3. When Add Volumes / Copies opens, the Owning Library will default to the library selected in the previous step.

4. Relevant copy selections will default to the library selected in the previous step.


1. Is Show Empty Volumes in Webby different from Hide Empty Libraries in XUL?

2. Is there still a need for the Limit feature that exists in XUL or is "at or below" sufficient?

Elaine Hardy (ehardy) wrote :


1) If I understand this correctly, y'all would like a return to the display of libraries and branches to be similar to the XUL client where the relation ship between org units is clearer. I think the problem here is how the web client aligns the systems and branches. Separate systems are often indented underneath another system as if they were a branch of the system rather than a different system. I've attached a screen shot illustrating what we see. If the alignment was corrected, would this address the issue in 1)?

2)Retaining the checkboxes in holdings view with the display of empty libraries is fine with us. Especially since you can check the box by clicking anywhere in the entry.

3) I would clarify by saying owning libraries, rather than library.


Scott Thomas (scott-thomas-9) wrote :

   Yes. If I am in a multi-library system, I should be able to select my system-level org unit and see all child org units in a clear fashion including those that have no volumes and copies...and then be able to add volumes and take other actions from there if I wish.

Kathy Lussier (klussier) wrote :

I added a mockup here - https://bugs.launchpad.net/evergreen/+bug/1716488/comments/5 - that we originally shared with Equinox back when we were first testing the cataloging code that shows how we envisioned an improved alignment. It doesn't address the empty libraries issue, but since alignment was mentioned here, I thought it would be worth posting the link.

Elaine Hardy (ehardy) wrote :

That looks much better.

Personally, I prefer the XUL layout which reinforces the hierarchical relationship of copy to call number/volume to library/branch to system. And makes it easier to spot when you have an error in a call number.

Scott Thomas (scott-thomas-9) wrote :

The mockup is an improvement. I also agree with Elaine's preference for a lay-out. We need to be able to see the org unit structure, whether empty or not, so we can right-click where an org units volume should go and then have the org unit selection carry through when you select Add Volumes and Copies.

Mike Rylander (mrylander) wrote :

The original issue reported is addressed by the branch at: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/holdings-view-omnibus

Kathy's follow-up request for changing the layout of the Owning Library is not addressed here. I think that's a separate wishlist bug.

tags: added: pullrequest
tags: added: signedoff
Jason Stephenson (jstephenson) wrote :

I tested Mike's branch and everything works for me. I pushed a sign off branch to working/user/dyrcona/holdings-view-omnibus-signoff:


I haven't pushed it to master, etc., because I think we should have an actual, working cataloger look at the changes before this goes in.

Changed in evergreen:
milestone: none → 3.next
Elaine Hardy (ehardy) on 2018-05-04
tags: added: webstaffblocker
Elaine Hardy (ehardy) wrote :

I am testing and seeing problems. More tomorrow after I do more testing.

Elaine Hardy (ehardy) wrote :

From my testing, libraries with no vols attached do show up in holdings view now. However, there are a couple of errors:


Workstation library is for headquarters – STATELIB-L

Attempting to add vols and copies to branches STATELIB-B and STATELIB-L

Error #1
Select multiple libraries with no volumes attached, from action menu, select Add – Volumes and copies
Rather than volumes for selected libraries, display is to add 2 copies to workstation library

Error #2
Add volumes to selected libraries, then attempt to add copies (must redisplay holdings view to see added vols)

Volumes successfully added, so select libraries, then Actions menu – add copies.

A. Apply templates with circ lib set to either library, fails. Saves with no addition of copies.

B. Apply template with no circ lib set, shelving location to STACKS (STATELIB-L), book, available, etc. Applying template does not change default circ library (workstation library STATELIB-L) to <unset> in copy editor. Cannot manually unset circ library.

Save & Exit,vol/copy editor closes. Must redisplay record to see holdings. Attributes appear to be correct but can’t read circ library, call number, status, or barcode.

After removing columns and expanding circ library column width, then saving column config, can see that Circ library for both is STATELIB-L

Must edit circ library in copy editor to correct library.

Attaching doc with screenshots illustrating above workflow

Elaine Hardy (ehardy) wrote :

I don't agree that the needed changes to how libraries display in holdings view classifies as wishlist. The current web client display is not in parity with the XUL client holdings maintenance display and creates a barrier to clearly and efficiently seeing the structure of libraries and holdings.

Mike Rylander (mrylander) wrote :

Thanks, Elaine.

While I haven't yet attempted it, your first error is new and specific to the change here. The rest look like variants of several other preexisting LP bugs.

For the record, copy circ lib cannot be NULL in the database, and so cannot be set to <unset>.

Elaine Hardy (ehardy) wrote :

Understand that circ lib can't be NULL in database, however, previously in the web client, when cataloging multiple branches at one time, using a copy template with an <unset> circ library put <unset> in the data well for circ library at least some of the times, copy templates are unstable in the web client). When the copies were then saved, the correct circ library was assigned to the correct vol/copy. That is not the behavior I am seeing now.

Elaine Hardy (ehardy) wrote :

Did not notice this when testing since I had Holdings view limited to 25 and the record had 46 holdings attached. When view is set for consortium level, the empty libraries are added at the end of the libraries with holdings rather than within the individual library.
Currently, Show holdings at or below PINES and Show empty volumes, show empty libraries, show copy details, and show volume details are all checked, holdings are displayed as:

ARCPLS-DIAML Diamond Lakes Branch Library 31019003273979 FIC WEB
ARCPLS-FRMAN Friedman Branch Library 31019003273987 FIC WEB
ARCPLS-MAIN Augusta-Richmond Co. Public Lib. 31019003273961 FIC WEB
CCL-RING Catoosa County Library 31687002412309 WEBER, DAVID
CLAYTN-FOR Forest Park Branch 31012002832028 A FIC WEBER, DAVID
DCPL-CEN Central Branch 31018002661200 F WEBER, DAVID
FRRLS-FA Fayette County Public Library 31022007284679 SF WEBER
FRRLS-JA Jackson-Butts County Public Library 31022007182634 SF WEBER
Etc… for all libraries

For clarity, display should keep empty libraries/branches within library system:

ARCPLS-DIAML Diamond Lakes Branch Library 31019003273979 FIC WEB
ARCPLS-FRMAN Friedman Branch Library 31019003273987 FIC WEB
ARCPLS-MAIN Augusta-Richmond Co. Public Lib. 31019003273961 FIC WEB
DCPL-CEN Central Branch 31018002661200 F WEBER, DAVID
FRRLS-FA Fayette County Public Library 31022007284679 SF WEBER
FRRLS-JA Jackson-Butts County Public Library 31022007182634 SF WEBER

Scott Thomas (scott-thomas-9) wrote :

We are at 3.0.7. I just tested this. We can now get libraries with no volumes and copies to appear in Holdings View which is great, but when you select an empty library and choose Add Volumes and Copies, the Owning Library defaults to the workstation library and not the org unit that was selected in the previous step. Are there plans to fix this as well?


Mike Rylander (mrylander) wrote :

Yes, Scott. This bug isn't closed, and future improvements are planned.

Remington Steed (rjs7) wrote :

I can confirm the regression described by Scott (in #31) and Elaine (in #26). We will be taking a closer look at this.

Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :

Close to having a patch to address the regression noted here, and hopefully simplify the code in the process. I expect to have something to share very soon.


Dan Wells (dbw2) wrote :

Okay, I humbly offer my proposed patch here:



While the change looks large, a good bit of it is reverting previous changes to contain the bug noted here. This also fixes the regression only; other potential display and workflow tweaks can come later. My reasoning behind this patch:

- Existing code distinguishs 'adds' from 'edits' via two wrappers, spawnHoldingsAdd and spawnHoldingsEdit. With this commit, empty volume adding now extends the 'add' function rather than the 'edit' one, as this seems more intuitive.

- The previous change had extended both the catalog app and another similar directive which is only used in a merging context. Since the merge context had no ability to add anything, and the new code was not wired up to any interface, this has simply been removed (for now).

- The volcopy app is set up around the concept of passing in 'prototype' vol/copy objects of varying degrees of completeness. It then loops over these to generate the interface. The previous code
extended this setup with a loop over a potential 'owners' array to generate empty volumes, but this unrelated loop within a loop seemed counterintuitive (and was the source of the original bug). This change has been removed, and empty volume creation now hews more closely to the original model.

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
Dan Wells (dbw2) on 2018-05-25
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :

Moving discussion to an omnibus bug for the omnibus branch...

Please see bug #1773417.

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers