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

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.

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

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

Is it possible to add it back to 3.0.12?

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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