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

[Janet Schrader]

On the copy record screen, if I use the 'copies' button to increase the number of copies to 2 or more, I get the additional barcode lines. However only the first barcode shows in the working copies tab on the left of the screen and only the first copy is created when I click on save & exit. This is a big problem for large libraries that often attach multiple copies to the same bib record at the same time.

Release 3.0.12 including cataloging omnibus bug fixes

[Kathy Lussier (klussier)]

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.

[Kathy Lussier (klussier)]

Adding a note that I confirmed the behavior on a 3.1.6

[Elaine Hardy (ehardy)]

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.

[Kathy Lussier (klussier)]

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.

[Kathy Lussier (klussier)]

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.

[Janet Schrader (jschrader)]

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. :(

[Elaine Hardy (ehardy)]

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.

[Elaine Hardy (ehardy)]

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.

[Elaine Hardy (ehardy)]

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

[Mike Rylander (mrylander)]

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.

[Dan Wells (dbw2)]

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

[Dan Wells (dbw2)]

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

[Dan Wells (dbw2)]

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.

[Janet Schrader (jschrader)]

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.

[Jason Stephenson (jstephenson)]

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.

[Cesar V (cesardv)]

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

[Cesar V (cesardv)]

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