Users without UPDATE_VOLUME perm can orphan copies in the copy/volume editor

[Chris Sharp]

Found in PINES. Staff with the UPDATE_COPY permission but not the UPDATE_VOLUME permission attempting to use the unified copy/volume editor to edit a call number receive two click through error messages. The first is a PERM_FAILURE for UPDATE_VOLUME. The other is : error in stash and close, acn_id = -1

Rather than the expected behavior when the error messages are acknowledged where the call number is not edited, the copy is disassociated with the bib record and a pre-cat like record is created with TCN -1 and no title.

See the attached screenshot for an example.

Evergreen 2.9.1
OpenSRF 2.4.1
PostgreSQL 9.4
Ubuntu 14.04 LTS

[Michele Morgan (mmorgan)]

Adding a link to a possibly related bug:

https://bugs.launchpad.net/evergreen/+bug/1253732

which is in turn related to:

https://bugs.launchpad.net/evergreen/+bug/1040686

Perhaps a simple solution to some of the issues related to the unified editor always creating a new volume record would be to add a check that the new volume actually exists prior to trying to transfer the item to it.

Also worth noting here is that 1040686 is fixed in webby, so this issue may be as well.

[Michele Morgan (mmorgan)]

We have recently seen a variation of this bug on our 2.9.1 production system and have also reproduced it on a 2.10.5 test system.

In this variation, the user who has UPDATE_VOLUME and UPDATE_COPY at the System level is able to edit an item outside of their system and cause a precat situation on another library's item.

Here are the steps to reproduce:

- Login as a staff user that has UPDATE_VOLUME and UPDATE_COPY permission at the system level.
- In Item Status, retrieve an item belonging to a different system.
- Choose Actions for Selected Items - Edit Items/Volumes per Bib
- Change a field in the call number
- Change a field in the copy record
- Click Re-barcode/Update Items
- When prompted for authorization to UPDATE_VOLUME, click Cancel
- Acknowledge two pop-up errors.
- Choose Actions for Selected Items - Show Item Details.

The item is now UNCATALOGED

We became aware of this when a staff user opened another library's item in error, edited the barcode, call number, and applied a template that updated the copy.circ_lib. This essentially deleted the original item. It became uncataloged with a different barcode and circ lib. Only in consulting the auditor tables was the original data discovered.

Here's a link to a screencast showing the steps that result in the uncataloged item:

http://screencast.com/t/IFHYWTY2zx

[Andrea Neiman (aneiman)]

Noting that I am unable to replicate this in the web client, 3.0.0. If I try to recreate Chris's steps with a user that has UPDATE_COPY but not UPDATE_VOLUME, I get a prompt to log in with the correct permissions. If I click cancel, the item area of the screen clears (a very minor issue on its own), but the item does not detach itself from the record/volume.

Trying to recreate Michele's steps in comment #3 with an out-of-system item, I get the same results -- prompt to log in with correct UPDATE_VOLUME permissions & the item screen clearing (with the exception of price), but the item does not detach.

Marking as fixed in webby.