Web Client: Unable to Add Items from Item Status or Holdings View

[John Amundson]

Evergreen Web Client 3.0.12

I believe this bug was introduced somewhere between 3.0.8 and 3.0.12 as we only started noticing it after the upgrading from .8 to .12

I'll mainly discuss this issue as it relates to Holdings View, but the same bug is prevalent from Item Status when selecting Actions>Add>Items.

In Holdings View, select an already created volume, (empty or otherwise), and go to Actions>Add Copies.
The Vol/Copy Editor screen will appear but it will be missing the fields present in "Volume/Copy Details" pane on the top of the page, (see attached screenshot).

Because of this, the Barcode box is missing and therefore there is no way to create a copy and save & exit, effectively negating this action's purpose.

Not having access to CN Prefix, Call Number, etc since you are not adding a volume makes sense, but Barcode, Copy #, and Part should all still be present.

If an empty library is chosen, selecting to add copies will pull up the editor with the "Volume/Copy Details" pane intact.

In 3.0.8, this pane is always present when this action is used, and a barcode can be added.

[Kathy Lussier (klussier)]

I confirmed the behavior from Holdings View. This is a serious regression that will negatively impact the workflow of catalogers. As a result, I'm setting the priority of this bug to High.

[Kathy Lussier (klussier)]

Adding a note that I confirmed the behavior on a 3.1.6 system.

[Elaine Hardy (ehardy)]

I am not seeing this behavior on our test server with 3.2. When I select a library with or without vols or items attached, then actions -- add -- items, the input wells to add barcodes are present as expected. I also access the input wells as expected in item status

[Janet Schrader (jschrader)]

Is it possible to add it back to 3.0.12?

[Jason Stephenson (jstephenson)]

I believe that I have been able to reproduce this with a fresh installation of master, using concerto data.

See the attached screenshot. It looks different from John's, but we're still missing essential bits.

[Jason Stephenson (jstephenson)]

Unfortunately, the community will not back port any fixes to 3.0 at this point. It is now in security-only status for the next six months.

That said, anyone still running 3.0 on their local installation can attempt to back port any fixes to their system that they feel are important enough to install.

[Kathy Lussier (klussier)]

I see the following the Console when this problem occurs on my 3.1 system

[PCRUDContext 19]: open-ils.pcrud.search.acpl.atomic failed.
code => 500
status => Severe query error -- see error log for more details
params => ["3ad9cbd97fad576c6310e1004b7d1f59",{"id":[]},{"flesh":1,"flesh_fields":{"acpl":["owning_lib"]},"order_by":{"acpl":"name"}}]
err @ core.bundle.js:1
core.bundle.js:1 [PCRUDContext 19]: open-ils.pcrud.search.acpl.atomic failed.
code => 404
status => An unknown server error occurred
params => ["3ad9cbd97fad576c6310e1004b7d1f59",{"id":[]},{"flesh":1,"flesh_fields":{"acpl":["owning_lib"]},"order_by":{"acpl":"name"}}]
err @ core.bundle.js:1

and

Possibly unhandled rejection: {"session":{"service":"open-ils.pcrud","remote_id":null,"locale":"cs-CZ","tz":"America/New_York","last_id":1,"requests":["..."],"onconnect":null,"thread":"0.337251767240518641539182530473"},"reqid":0,"method":"open-ils.pcrud.search.acpl.atomic","params":["3ad9cbd97fad576c6310e1004b7d1f59",{"id":[]},{"flesh":1,"flesh_fields":{"acpl":["owning_lib"]},"order_by":{"acpl":"name"}}],"api_level":1,"response_queue":[],"part_response_buffer":"","complete":false}
a

In reference to Jason's last comment, I think an exception should be made to the 3.0 release. When a serious regression is introduced in the last point release of an Evergreen series, it needs to be fixed.

[Kathy Lussier (klussier)]

I do NOT see this problem on the Equinox community demo server, which is running the 3.2 RC.

[Mike Rylander (mrylander)]

I have not looked at the code (3.0 or later) yet, but the error that Kathy pasted shows that we're making a call to retrieve a set of copy locations by id, but not supplying any IDs.

[Jason Stephenson (jstephenson)]

Just confirming that I get the error mentioned by Kathy in comment #8 on master.

[Dan Wells (dbw2)]

This appears to be some more promise-based out-of-order-ness. I have a workings solution, but I am not sure it is good at this hour, so going to sleep on it and possibly post tomorrow.

[Dan Wells (dbw2)]

Okay, potential fix is here:

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

working/user/dbwells/lp1796971_wait_for_call_number_copy_load

This problem also seemed to result from the branch labeled for bug #1732761, which from my casual looking is rather mysterious, as I'm not seeing a record in LP as to when that branch got pushed. (It was not in the omnibus, as suggested on the bug.) *shrugs* To be clear, I only mention this for the possibility of reviewers digging deeper to avoid regressions.

Anyway, from the commit message!:

In cases where add a copy to a call number, we fetch the original call number via async, then attach the new copy to it. Before this commit, however, we were not waiting for the call number fetch promise to resolve, so the copy wasn't there to use for limiting the location load.

Since the async request is internal to a loop, one way out is to capture that promise, then make sure it resolves before loading the locations.

Please note I still consider myself a relative novice when it comes to JS promises. While this is far from the only way to resolve this bug, it seemed to me to be the simplest without upending even more of the structure.

Dan

[Kathy Lussier (klussier)]

I think that earlier bug should have been marked as a duplicate of bug 1738890 instead of the Omnibus branch. I'll update it with the correct information.

[John Amundson (jamundson)]

This looks good to me. I tested on 3.0.12 system that had the patch for this and bug 1796978 installed. I was able to add items in both Item Status and Holdings View using Actions>Add>Items and Actions>Add Copies, respectively. The patch didn't seem to have any negative impacts on bug 1738890 or bug 1732761.

I have tested this code and consent to signing off on it with my name, John Amundson and my email address, <email address hidden>.

Thank you Dan, Jason, and Kathy.

[Jason Stephenson (jstephenson)]

I pushed a signoff branch based on master to user/dyrcona/lp1796971_wait_for_call_number_copy_load-signoff:

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

It has signoffs for both John and myself.

I pushed the commit to rel_3_0 but I'm leaving it for 3.1 and 3.2 for others to test.

[Cesar V (cesardv)]

I've tested the latest patch branch (the one signed off by Jason S., Dan, and John) and it seems to address the bug described in this LP on the latest working master code. So here's yet another signoff:

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

I will note that since bug 1746536 has yet to be merged in, calling the volcopy editor to Add/Edit volumes from the Item Status is still buggy (broken), but that is separate to this.

I think merging this in and the related refresh bug 1796978 with the volcopy editor working copy grid, should do the trick.

[Cesar V (cesardv)]

Went ahead and pushed this to master, rel_3_2, and rel_3_1. Thanks guys!