Web client cannot create two or more copies at the same time

Confirming. 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

In 3.2 on our test servers, I am able to successfully add more than one copy to a volume. However, no barcode displays in the working copy tab, not even the first one.

Elaine,

When you saved items in your testing, did all of the items save? In my case, it looked like I could add all items, but only one of those items successfully saved.

I was able to reproduce this behavior on the Equinox community demo server running the 3.2 RC.

I have a little more detail.

If I click add call numbers / items, increase the number of items to 3, and then add all three barcodes, only one barcode shows in the working tab, as was previously described. I click to save the items, and only that one barcode saves.

However, if before saving, I adjust the column widths in the working tab, and then close the column width tool, all three barcodes now populate that tab. When I click save, all three items are saved.

I'm not suggesting this as a workaround, but the problem is clearly related to the working tab no longer properly populating its barcodes.

Amazing!! I can confirm this. I believe we have identified the problem. I was able to use Kathy's directions to create 3 copies on my production server release 3.0.12. I reconfigured the working tab columns and voila!! it worked. Unfortunately it's not sticky so adjusting the columns would have to be done every time. :(

Kathy,

Yes, all the items saved successfully. I am going to check changing the column width to get the barcodes to display on the working tab. But even without them, I am able to successfully save/add multiple copies.

I was to a vol with an existing copy. Let me test if no copies are attached yet.

I imported a record and then added vols/copies -- holdings view, select libraries -- actions -- add-- vols and copies. Used counter to add 6 copies. Data wells opened as expected.

Without adjusting the column size for the working tab, I successfully added six copies. While the barcodes did not display in the working tab, a row for each did (see attached screen shot). Entered barcodes (fake ones so typed in), Applied template and was able to save & exit. (see attached for added copies)

I then added vols/copies as above for a different library. This time I adjusted the column width and was able to view the barcodes. (see attached) Also able to successfully add copies.

I can confirm that the resizing does not stick, even after saving the columns.

Still haven't looked at the code, but for anyone that does get to it before me, it sounds like a grid.refresh() is needed somewhere that is no longer happening. I believe changes to grid layout trigger that, which would explain the resize "fixing" things.

This feels awfully familiar to the checkout grid bug, so I'm going to take a poke in that direction.

Ok, this looks like a simple bracket alignment/counting problem. Branch incoming...

Okay, branch is here:

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

working/user/dbwells/lp1796978_refresh_working_copies

From the commit:

The "working copy" grid needs to update whenever the copy data above updates. I *believe* this aligns the refresh with its intended condition.

This appears to have come about via bug #1732761, so retesting of that fix may be in order.

More specifically, the change happened here, so it looked to me like a hard thing to test definitively:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=140ff94d566acf262486152bad8395b32429ed4b

Finally, this change brings about some type error warnings in the console, but I don't believe those are directly related.

I tested this bug on release 3.0.13 and was successful in adding mulitple items at the same time, both by selecting the library in holdings view and by clicking on the 'add copies' button. I can confirm it works in this release.

Thanks to Janet for testing!

I have added my signoff to a branch based on master here:

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

I have pushed the fix to rel_3_0, and leave the testing with 3.1 and 3.2 to someone else.

Tested this fix in on latest master, in conjunction with bug 1796971 and it seems to address the issue(s).

Pushed this to master, rel_3_2, and rel_3_1. Thanks guys and gals.