web client: cannot edit vol/call number in item status

[Elaine Hardy]

In item status, when using the action menu, edit volume or edit copies and volumes, the boxes in the volume editor are grayed out and cannot be edited. The "no" symbol is displayed.

From item status, to edit volumes/call numbers, you must show the record in the catalog and ether from holdings view, actions menu or OPAC view edit at individual bacodes, to edit.

[Christine Burns (christine-burns)]

Confirm this is still happening in version 3.1

[a. bellenir (abellenir)]

services/item.js defines the service.spawnHoldingsEdit function that explicitly sets `record_id: 0, // disables record summary`

the user/abellenir/lp1746536-edit-volume-from-item-status branch (http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/abellenir/lp1746536-edit-volume-from-item-status) will supply the record_id if (and only if) exactly one record is selected.

selecting several copies that all belong to the same record seem to work ok, but i wasn't sure how to best handle having multiple record_ids to choose from, so kept the behavior unchanged.

[Janet Schrader (jschrader)]

Libraries often batch edit only the volume field to remove a prefix such as "New" or "Ref"". They need the ability to scan in multiple barcodes for items attached to multiple bib records and select "Edit volumes" like they can do in the xul client. Only the list of volumes displays and they can apply a batch change to remove/add a prefix or just go down the list highlighting and removing or adding text to a the volumes. Much faster than opening multiple bib records.

[a. bellenir (abellenir)]

Janet, thank you for clarifying!

can you perform the required operation, editing barcodes belonging to various records, elsewhere in the web staff client? if so, where?

having a reference would be helpful in getting this working as needed.

[Janet Schrader (jschrader)]

The only place to edit multiple items attached to different bib records is Item Status. I don't know of any other place to do this.

I can edit batch edit item attributes from Item Status if I select "edit items" or "edit volumes and items". If I select the latter the volumes are there but grayed out.
I can also replace multiple barcodes from item status. Selecting "replace barcodes" provides consecutive popups where I can enter each barcode, a popup for every item selected.

There is a bug where you cannot edit an item with a part. If one of the items has a part all batch edits fail.

[Dan Wells (dbw2)]

While I don't think there's overlap yet, this seems likely to run headlong into bug #1773417 if it gets too ambitious. I'd hope to see that get more review before pushing into this, as there's a bunch of redundant code which needs some cleanup love in this area, and diverging too much here could make that trickier.

Dan

[Andrea Neiman (aneiman)]

Multiple items attached to different bibs can also be batch-edited from Copy Buckets, as this will invoke the same copy edit interface that Item Status will. If you click on "Show Volume/Copy Details" you can edit the barcodes attached to different volumes.

Also, +1 to Dan Wells' suggestion of getting 1773417 settled before this goes much further.

[a. bellenir (abellenir)]

(rm'd pullrequest tag since the proposed change does not meet requirements and it sounds like bug 1773417 should take priority)

[Jane Sandberg (sandbergja)]

I am marking this as webstaffblocker. This is functionality that was available in the Xul client, but not the Web client. It is a very common task for catalogers.

[Janet Schrader (jschrader)]

+1 (a little late) to Jane Sandberg's webstaffblocker. This missing functionality means we still need the xul client. CWMARS considers this high priority.

[Cesar V (cesardv)]

Here's a patch that builds upon A. Bellenir's branch above and enables multi-bib volume editing:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/cesardv/lp1746536-multibib-volEdit-from-itemstatus

Should also address bug 1739290 as well.

[Beth Willis (willis-a)]

I tested both code from both the branch and patch on our server running EG 3.2-beta 1.

I followed these steps:

I uploaded a file of barcodes to Items Status. The barcodes were attached to volumes associated with multiple bib records.
I selected all of the items
I selected Actions-->Edit-->Volumes.
I was able to edit individual volumes. However, there was no "Batch Apply" option available as there is in the XUL client.
I then selected volumes associated with only ONE bib record. In this case, the "Batch Apply" option was available.

I also looked at the Actions-->Edit-->Volumes and Items option. This works the same way: if volumes from only one bib record are selected for editing, the "Batch apply" option is available. If volumes from multiple bib records are selected, it is not available.

This option displays all volumes and items in one tab, though. This is an improvement over the XUL client where a tab opens for each individual bib record.

We often need to update volumes from multiple bib records in batch. This feature should be restored. I have attached screen captures from the XUL client and from the Web client.

[Beth Willis (willis-a)]

Sorry, only one of my screen captures was saved to my previous comment. This one shows the Edit-->Volumes screens in the XUL and Web Clients.

[Mike Rylander (mrylander)]

I can't find a reason to restrict the Batch Apply actions in this context, so I've removed the "must have a record" test. Here's a branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1746536-multi-record-batch-vol-apply

[Mike Rylander (mrylander)]

Sorry, I' retracting that branch ... I'll force-push a different one built upon Cesar's.

[Mike Rylander (mrylander)]

OK! Here's the same change atop Cesar and abellenir's branch, with signoffs for their commits:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1746536-multibib-volEdit-from-itemstatus-signoff-fixup

[Kathy Lussier (klussier)]

After loading the latest branch, I am unable to load the vol/copy editor. There was a minor conflict when I picked Cesar's branch that seemed fairly straightforward to resolve, but maybe I somehow messed up the resolution. I can't think of another explanation as to why it worked last week for Beth but no longer works for me.

I see the following in the Console:

Uncaught SyntaxError: Unexpected token <<
jquery.min.js:2 Uncaught Error: [$injector:modulerr] Failed to instantiate module egVolCopy due to:
Error: [$injector:nomod] Module 'egVolCopy' is not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument.

https://errors.angularjs.org/1.6.10/$injector/modulerr?p0=egVolCopy&p1=Error%3A%20%5B%24injector%3Anomod%5D%20Module%20'egVolCopy'%20is%20not%20available!%20You%20either%20misspelled%20the%20module%20name%20or%20forgot%20to%20load%20it.%20If%20registering%20a%20module%20ensure%20that%20you%20specify%20the%20dependencies%20as%20the%20second%20argument.%0Ahttps%3A%2F%2Ferrors.angularjs.org%2F1.6.10%2F%24injector%2Fnomod%3Fp0%3DegVolCopy%0A%20%20%20%20at%20https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A653%0A%20%20%20%20at%20https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A10987%0A%20%20%20%20at%20t%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A10448)%0A%20%20%20%20at%20https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A10761%0A%20%20%20%20at%20https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A18891%0A%20%20%20%20at%20o%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A1085)%0A%20%20%20%20at%20d%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A18739)%0A%20%20%20%20at%20ut%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A20754)%0A%20%20%20%20at%20r%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A8772)%0A%20%20%20%20at%20ue%20(https%3A%2F%2Fmlnc1.noblenet.org%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fvendor.bundle.js%3A6%3A9085)
    at vendor.bundle.js:6
    at vendor.bundle.js:6
    at o (vendor.bundle.js:6)
    at d (vendor.bundle.js:6)
    at ut (vendor.bundle.js:6)
    at r (vendor.bundle.js:6)
    at ue (vendor.bundle.js:6)
    at le (vendor.bundle.js:6)
    at HTMLDocument.<anonymous> (vendor.bundle.js:6)
    at l (jquery.min.js:2)

[Galen Charlton (gmc)]

Based on the error message, looks like a merge conflict marker snuck in. I've rebased the branch and signed off on it; the latest branch is user/gmcharlt/lp1746536_rebased.

[Kathy Lussier (klussier)]

Bah! Yes, that was the problem. Sorry about that.

I took a look at the rebased branch. I found two issues.

When I select Edit Call Numbers for a single or a batch of copies, everything works as expected. I can batch apply call number changes now and I can edit call numbers individually.

If I select Edit Call Numbers and Items for a single item, everything works as expected. I can make changes to both the call number and item fields.

However, if I select multiple items and use Edit Call Numbers and Items, the individual call number fields are disabled for editing. I can still use the batch apply in this instance to make the same change to all of the selected call numbers, but I can't make a change to an individual call number.

The second issue is with the alignment of boxes in the edit Call Number area. Pre-patch, I selected two call numbers from Holdings View to edit. All of the input fields were aligned neatly under their column headings. See screenshot at http://www.screencast.com/t/oIBlq9GIEXeD. Post-patch when editing the same two call numbers from Item Status or from Holdings View, the Org Unit Shortname displays twice and the line breaks after the field that shows the number of call numbers. Nothing is lined up correctly under its column heading. See http://www.screencast.com/t/r8bq9NOnFTlo.

Thanks all!

[Mike Rylander (mrylander)]

We currently disable volume editing if there are multiple records involved. Should we simply stop restricting the top half of the UI in that way?

NOTE: We do need to continue restricting the /addition/ of new call numbers in the case of multiple records, however, because ... which record do we add it to?

[Kathy Lussier (klussier)]

Disclaimer: I am not a cataloger, nor have I run this question by a catalog, so I may be missing something.

However, looking closely at this, I think we can stop restricting the top half of the UI in that way when there are multiple bib records. We're already doing so when selecting 'Edit Volumes,' which gives us feature parity with the same action available in xul, and if we can edit volumes across multiple bibs there, I don't see why it would be a problem to do so when we're editing volumes and items at the same time.

+1 to restricting the addition of new call numbers in the case of multiple records. However, right now, it appears as if you can do so when you are editing volumes across multiple bibs. I clicked add, entered the call number information, and hit save with no indication that there was a problem saving this new call number. However,as far as I can tell, it doesn't save, probably because it doesn't know which bib record to use. Can we restrict it by disabling that button?

Thanks Mike!

[Mike Rylander (mrylander)]

I've pushed a commit to my branch to do both of those things.

Thanks, Kathy!

[Kathy Lussier (klussier)]

Thanks Mike! Editing the barcodes from Item status looks good now, but we found another issue with this branch when adding items to existing call numbers. This issue was originally reported to me by one of our catalogers, Janet Schrader.

When I select the 'add items' option from a call number in holdings view, the entire Call number line is now removed from the display. This is problematic because this is where we add barcode numbers and parts. I tested this same workflow on an older master system that is not running the code and did not see the same behavior.

[Kathy Lussier (klussier)]

Another issue discovered by Janet.

If I click add Holdings from the record (doesn't matter which view) and then try to add two more items by incrementing the items input:

- The entered barcodes don't display in the Working Tab - this problem occurs regardless of the number of items I add.

- When I click to save the items, only one items saves.

I'm also posting a link to the rebased branch I am now using to test this code since I had to resolve a couple of conflicts. I added the signoffs before Janet reported the problems she saw.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1746536_rebased_signoff

[Kathy Lussier (klussier)]

Adding a note that the issues discovered in testing are not a result of this code as we are now seeing this behavior in existing Evergreen releases.

[Andrea Neiman (aneiman)]

I'll take a closer look tomorrow or Friday, but hopefully the fix for bug 1796978 addressed the issues in comments 23 and 24.

[Janet Schrader (jschrader)]

We have the fix for bug 1796978 on production now and it does resolve issues in comment #24 (sorry, don't know how to make the text in the comment a link).
https://bugs.launchpad.net/evergreen/+bug/1796978
We also have the fix for bug 1796971 and it resolves the issue in comment #23.
https://bugs.launchpad.net/evergreen/+bug/1796971

[Galen Charlton (gmc)]

I confirm the results of Janet's testing in comment #27 and have pushed this to master and rel_3_2. Thanks, folks!

[Galen Charlton (gmc)]

And now pushed to rel_3_1.