Unified editor shouldn't always delete volumes

Bug #1040686 reported by Ben Shum
70
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Undecided
Unassigned

Bug Description

Evergreen master

We first noticed this when we were tracking down the reason why a whole bunch of volume holds were cancelled with "untargeted expiration". It turns out that the volume they were targeting was marked deleted. It seems that using the unified editors always creates a brand new volume entry instead of editing / replacing the label if it was changed.

This occurred for us when using either the option to "Edit Items/Volumes Per Bib" from Item Status or when modifying the item directly via holdings maintenance. It would always create a new volume and apparently move the copies to that volume while marking the previous volume deleted. Using the options to "Edit Volumes" to change the label safely kept things where they were.

While the volume cancellation is odd and bad too, I'm more concerned with the number of potential dead rows we're creating as a result of editing / modifying our call numbers. Having all these extra entries seems like a waste.

Tags: fixedinwebby
Revision history for this message
Kathy Lussier (klussier) wrote :

We have also seen volume holds cancelled after staff changes the label for a volume. This usually happens when changing a call number from something like "On Order" to its real call number. We would prefer that the unified editor replaces the current label rather than creating a new one.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Elaine Hardy (ehardy) wrote :

PINES libraries have noticed that using the "Edit Items/Volumes Per Bib" in Item status to edit a call number creates an empty volume and does not edit the call number on the existing volume. Nor does it appear to transfer the items to the new volume. We request that the "Edit Items/Volumes Per Bib" interface edit the existing volume and not create an empty one

Revision history for this message
Elaine Hardy (ehardy) wrote :

Misspoke in the previous comment. Need more coffee ... "Edit Items/Volumes Per Bib" does indeed create a new vol and move the existing items to that volume, leaving an empty volume with the original call number. We do request that the unified editor replaces the current label rather than creating a new one.

Revision history for this message
Kyle Tomita (tomitakyle) wrote :

Ben,
Can you explain how to modify the item directly via holdings maintenance? By item do you mean volume? I am not familiar with this area.

When I right click on a volume and go to "Edit Volume" then it modifies the volume and not create a new one.

Revision history for this message
Kathy Lussier (klussier) wrote :

Hi Kyle,

This problem occurs when using the unified volume/copy editor. To see it happen, you need to make sure the Unified Volume/Item Creator/Editor OU Setting is set to "True." You then either need to double-click the item from Holdings Maintenance or select "Edit Items." Or you can use the option that Elaine described in her comment.

If you change the call number in the top pane and then select re-barcode / update items, Evergreen will create a new volume and then move the item to this new volume. In our case, if the edited item was the last belonging to that call number, Evergreen will then automatically delete the old volume (we have enabled the setting to make this happen), so it appears to the user as if it simply replaced the call number, when in fact it moved it to a new one.

This is problematic because any holds associated with that call number are then lost.

I hope this helps clarify things!

Kathy

Revision history for this message
Michele Morgan (mmorgan) wrote :

We are still experiencing this issue in our 2.4.3 system.

It would certainly be preferable that the unified editor NOT create a new volume when the item(s) being edited is(are) the only ones attached to that volume. Deleting the volume in this case is not necessary and creates a whole lot of unnecessary deleted rows in the call number table.

But another approach which would resolve the "untargeted expiration" hold cancellations would be to make sure that whenever the unified editor deletes an old volume, that any holds on it get transferred to the new volume that is being created.

While it doesn't feel like the cleanest way to handle this, it would solve the problem for our staff users who need to do extra work to manage volume level holds because of this bug.

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

An update from 2.7. It also appears that the volume is deleted even if the user does not have any volume permissions. So, if a user has UPDATE_COPY permission and gets to the volume copy editor (such as by clicking the "edit" link next to the barcode in the TPAC) and makes any changes to the call number, the volume is deleted. The system apparently does check for the CREATE_VOLUME permission because the new acn is not created and the item is then attached to the -1 pre-cat call number, causing even more confusion.

The simplest way to stay safe from accidental volume deletion until this is fixed is to hide that link altogether (templates/opac/parts/record/copy_table.tt2) and force circ staff to use the "Replace Barcode" menu item under the Circulation menu or Edit Item Attributes from Item Status; depending on what they need to do.

Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

We are on 2.8 now and still experiencing this issue.

The unified volume/copy editor is very helpful to cataloguers because they can edit the call number and item barcode at one shot when handling on order items. But deleting/recreating the call number cancels volume level holds. This behaviour is really troublesome. The cataloguers have to choose to either edit volume and copy separately or check and transfer holds first before editing on the unified editor. This extra step of handling holds first offsets the convenience it brings to the cataloguers.

Tina Ji
BC Libraries Co-operative

Revision history for this message
Kathy Lussier (klussier) wrote :

Adding a note that this issue appears to be resolved in the web client. In my testing, I found that updating the volume in the new vol/copy editor in the web client modified the volume record rather than creating a new one. The update affected all the copies attached to that volume, as you would expect when a volume record is modified. Volume holds still filled after the update was made.

I know it will still be some time before we're all using the new client, but I just wanted to add a note that it will be fixed then if another xul fix isn't forthcoming in the meantime.

Kathy Lussier (klussier)
tags: added: fixedinwebby
Revision history for this message
Michele Morgan (mmorgan) wrote :
Revision history for this message
Kathy Lussier (klussier) wrote :

Setting this bug to Won't Fix since it is fixed in the web client and the xul client is now deprecated.

Changed in evergreen:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.