Web client edit single call number changes all when multiple items attached
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Undecided
|
Unassigned | ||
3.1 |
Fix Released
|
Undecided
|
Unassigned | ||
3.2 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
If there are multiple items attached to the same call number (volume) and you only want to edit the call number for a single item, making that edit changes all the other call numbers. This has been a known issue in out network since we moved to the web client but we cannot find anything about this on launchpad.
For example, with summer reading ending, a library may want to remove 'Summer Reading' from the call number of some items and move them into the regular collection while leaving some copies with Summer Reading in the call number. When they change the call number of one copy to put in the regular collection, it changes the call number of all 10+ copies.
Evergreen web client version 3.0.9
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
milestone: | none → 3.3-beta1 |
Changed in evergreen: | |
milestone: | 3.3-beta1 → 3.3-rc |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
In the xul client, we averted this issue in the unified editor by creating a new call number behind the scenes and transferring any items being edited to this new call number. This behavior also came into play when using the 'Edit Items/Volumes Per Bib" option in Item Status of the xul client.
However, there were a lot of complaints about this behavior in bug 1040686. We 'fixed' this bug in the web client, but I think it left us in a place where there is no easy way to update the call number for just some of the items attached to that call number. You can create a new call number and then transfer those items to the new call number, but I wouldn't call this workflow easy when compared to the old way of doing it in the Unified Editor.