Web client edit single call number changes all when multiple items attached

[Janet Schrader]

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

[Kathy Lussier (klussier)]

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.

[Scott Thomas (scott-thomas-9)]

This is a big problem for us and is causing some of our libraries to stick with XUL for cataloging functions. How can we get this functionality added back into Webby?

Scott

[Kathy Lussier (klussier)]

I wonder if it would be worth adding a sticky checkbox here, only available when editing both copies and call numbers at the same time, that indicates whether the call number should be updated for all items or not. Or perhaps we can revert back to the old, xul client behavior except in cases where the copy(ies) being edited is the last copy belonging to that call number. IIRC, the big complaint with this previous behavior wasn't necessarily that a portion of the items was moved to the new call number, but that the old call number was being deleted when we really just wanted it to do be updated. Deleting the call number would then cancel any volume-level holds.

The use case where this was particularly problematic was for on-order items. Once those items were received, the call number would be updated from On Order to the real call number, but all of those volume holds would be lost in the process.

[Janet Schrader (jschrader)]

Kathy, Do you really think library staff are placing volume level holds on on-order call numbers? Patrons cannot place volume level holds in our network. The majority of holds are title level for us, followed by part level as we use serial records for works that are continually published or in a series. I see volume level used when a staff person needs to get that particular item or when they want to be sure a patron gets a particular item attached to a record with parts when some items are missing parts. In the latter case it would never be an on-order call number.
Wouldn't it make more sense to link the old/new volume much as holds placed on a merged TCN are linked to the TCN of the kept record?

[Kathy Lussier (klussier)]

Janet - I am just summarizing what was already discussed on bug 1040686.

[Janet Schrader (jschrader)]

Please don't confuse me with facts. 🙂

So that previous bug means this is fixed?

Janet

On Thu, Sep 27, 2018 at 12:55 PM, Kathy Lussier <email address hidden>
wrote:

> Janet - I am just summarizing what was already discussed on bug 1040686.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1794588
>
> Title:
> Web client edit single call number changes all when multiple items
> attached
>
> Status in Evergreen:
> New
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1794588/+subscriptions
>

[Kathy Lussier (klussier)]

No, sorry about the confusion. bug 1040686 was the xul-era bug that was filed to report problems with the previous behavior in xul. This is the same behavior that your bug is seeking to restore. We set that bug to "Won't Fix" because the behavior is different in the web client.

What I'm trying to say is that people want the updating of call numbers to work differently depending on the particular use case. This is why I'm suggesting that we find a way to accommodate both behaviors, or to have the client behave differently when the copy(ies) being edited is the last copy belonging to the call number. It seems as if this isn't a one size fits all situation.

[Michele Morgan (mmorgan)]

We do have libraries that routinely place volume level holds on both On order items and items already in circulation. Generally it's when a library wants its own copies to fill the hold. This could be a patron's preference, or when the hold is for a homebound patron or book group. Having these holds cancel was problematic for us in the xul client and our libraries needed to learn to work around it.

We had lots of issues where opening an item in the unified editor and just making an edit to the call number would cancel the volume level holds.

Here's how I can picture it possibly working:

1. If the call number appearing in the unified editor is edited and has only a single item attached, the existing call number should be updated.

2. If the call number appearing in the unified editor is edited and has multiple items attached, a new call number could created and the item moved to the new call number.

In the second case, if there are volume holds on the original call number record, they could stay there, which is not perfect, but volume holds themselves are not perfect, and it would prevent them from cancelling.

There are more workflows to consider, but we need to make sure that the issues described on both bugs are handled. Volume holds shouldn't be silently cancelled and changing of call numbers for more items than intended by the editor should be prevented.

[Mike Rylander (mrylander)]

If I may make a generalization to Michele's proposal, would it work to make the decision about modifying an existing call number or creating a new one be based whether all the copies attached to the call number are eventually sent to the server?

[Elaine Hardy (ehardy)]

In the XUL client, you cannot edit the call number of one item attached to a volume because of the structure of volume record and item records - Item records are attached to the volume/call number record and are subordinate to the vol record. The call number is directly associated with the volume record and not the item record. In order to change the call number of one or more items attached to the volume record, while maintaining the call number of other items on the same volume record, you must transfer the items to a volume record with the desired call number in the XUL client. If none is attached to the bib record, you create an empty volume with that call number and then transfer the item(s).

The same behavior is in the web client. The holdings display in the web client doesn't illustrate the structural nature of library to volume.call number record to item record as does the XUL client holdings maintenance display.

[Janet Schrader (jschrader)]

Elaine,
I am able to edit a single call number/volume with multiple items attached in the xul client, version 3.0.9. I selected a single item by clicking on the edit link in the item summary list and changed that one call number.
Because libraries cannot do this in the web client we have been telling them to use xul. So far no one has complained that they cannot edit a call number there.
Janet

[Elaine Hardy (ehardy)]

Please don't confuse me with facts :)

I do all my editing of vols and copies from the holdings maintenance and now holdings view interfaces and you cannot edit a single item there....

[Elaine Hardy (ehardy)]

for the call number

[Kathy Lussier (klussier)]

Adding some clarification that the behavior Janet is describing happens when using the unified copy/volume editor. If the unified editor was not enabled in your client, you would see the behavior Elaine described.

Mike, to clarify, when you say "all the copies attached to the call number are eventually sent to the server", do you mean all of the undeleted copies attached to the call number are being edited at the time the call number is updated? If so, +1.

[Mike Rylander (mrylander)]

Yes, that's what I mean, Kathy. As soon as I can, I'll look at doing that. However, if anyone else wants to take a swing at it, please grab the bug!

[Michele Morgan (mmorgan)]

I had another thought about the behavior when volume level holds exist in the context of this bug.

If a new call number is being created as a result of the edit, ideally the staff member performing the edit should be notified that a volume hold exist and be presented with the option to leave the hold as it is or move it to the newly created call number.

If there are five items attached to a call number and the staff user is editing four of them, they would likely want to move the hold to the new call number. If they are editing only one item, they would likely want to leave the hold where it is.

[Andrea Neiman (aneiman)]

Just letting everyone know that PaILS has contracted with Equinox to address this bug & an adjacent issue. We'll post the branch here when it's ready for community review.

[Meg Stroup (mstroup)]

I see Andrea's 10/19/18 update, but I wanted to comment that SCLENDS (3.1.5) is also experiencing this bug.

For our use case: the State Library may have a single bibliographic record with 200 attached items. We see this a lot with federal and state documents. We discovered this issue when a cataloger was working with federal documents: specifically, they were trying to add individual volume numbers to items that share a common call number (trying to address some legacy cataloging practices). The bibliographic record itself is for the Code of Laws and has many thousand attached copies, so this issue would repeat approximately a 1,000 times.

Thanks to Equinox and PaILS for taking this on!

[Janet Schrader (jschrader)]

Adding tag regression as this was something that could be done (and still is) in xul so it's functionality lost in moving to the web client.

[Jason Etheridge (phasefx)]

I've pushed a working branch that implements Mike's proposed behavior: collab/phasefx/lp1794588-callnumber-edit

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1794588-callnumber-edit

commit 55539067c552107ada2f8be66a83265b0250572e

    LP1794588 Web client edit single call number changes all when multiple items attached

    This patch tweaks the behavior Cat.pm's fleshed_volume_update, aka
    open-ils.cat.asset.volume.fleshed.batch.update

    Previously, if a volume label was edited, all items attached to that
    volume would be essentially affected. Now, if only a sub-set of items
    for the original volume being edited are being edited along with the
    volume, then a new volume is potentially created instead, leaving the
    original volume (and its unedited copies) untouched.

    Auto-merging of volumes may still happen in both of these scenarios.

[Jason Etheridge (phasefx)]

Removing pullrequest pending a bit of optimization we can make here. Thanks Mike!

[Jason Etheridge (phasefx)]

Here we go:

collab/phasefx/lp1794588-callnumber-edit2

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1794588-callnumber-edit2

[Jason Etheridge (phasefx)]

Force pushed a different version of that last branch to account for (ignore) deleted copies.

[Jason Etheridge (phasefx)]

Taking this back out for MOAR bug fixing. Other things are using that API call. Thanks Andrea!

[Jason Etheridge (phasefx)]

Force-pushed a new version of the collab/phasefx/lp1794588-callnumber-edit2 branch.

Three cases here:
  1) We're editing a volume, and not its copies.
  2) We're editing a volume, and a subset of its copies.
  3) We're editing a volume, and all of its copies.

For 1) and 3), we definitely want to edit the volume
itself (and possibly auto-merge), but for 2), we want
to create a new volume (and possibly auto-merge).

[Janet Schrader (jschrader)]

I tested this on 3.2 and was successful in editing a single call number if I selected "edit call numbers and items" from the action menu or opened a single item record and made the edit. If I chose to "edit call numbers" then it edited the call number for all items attached to that call number. I believe this is the correct behavior as the "edit call numbers" choice is not specific to a certain item but to the call number itself.

I edited the call numbers through the 'edit' link in item summary; by selecting a single item in holdings view; and by selecting a single item in item status and choosing "edit call numbers and items" from the action menu. All of these choices open a single item record.

I can sign off on this bug: Janet Schrader, email <email address hidden>

[Andrea Neiman (aneiman)]

Hi Janet -- thanks for your testing, but Jason hasn't pullrequested this yet. We did some internal testing as well and there will be an updated branch posted with a pullrequest later this week.

[Jason Etheridge (phasefx)]

No further changes were actually needed for this branch, so Janet's sign-off should still stand. Adding a pullrequest. Thanks!

[Jason Stephenson (jstephenson)]

Pushed to master, rel_3_2, and rel_3_1 for catalogers everywhere.

Thanks Jason, Janet, and Andrea!