web client: cannot edit from item status in batch

[Kathy Lussier]

In the web client, if you scan in (or upload a file) of several items from different bib records, select them, and then select the edit option to edit those items, those items open into separate tabs, preventing you from doing a batch edit from the item status screen.

In the xul client, selecting Edit Items from the item status screen will open all of the selected items for editing in one screen.

[Andrea Neiman (aneiman)]

Confirmed 2.12

Noting for workaround purposes that you can add items in the status list to a copy bucket and batch edit via the bucket.

[Mike Rylander (mrylander)]

Just a note about the multiple tabs. Item Status opens one tab per bib, not per item, because the full copy/vol editor is record-focused, with the record summary at the top of the page.

[Cesar V (cesardv)]

A fix for this is here:

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

This now makes the Item Status's grid "Edit Items" action, work like the Copy bucket's "Edit Selected Items."

[Beth Willis (willis-a)]

I tested this patch on our development server (v.3.0.1).

This patch fixes the problem of multiple tabs opening if you upload multiple copies (from different bib records) into the Item Status screen and select the "Edit" option.
However, there are a few issues remaining:

1) the copy editor displays values for attributes only if the selected copies all share the same value; otherwise, no values display. In the xul client, all values display for all attributes even if every copy has a unique value. In this regard, feature parity has not been maintained.

2) The one exception that I noticed is that if a single copy is selected, the value for "Price" displays. But then if a different copy (or multiple copies) that same value continues to display even if it does not apply to all selected copies.

3) Our consortium requires values for statistical categories be entered in order to save a copy. When I select multiple copies to edit and the values for these attributes differ, no values display and I am unable to save the copies. It would not be unusual to batch edit a number of copies that do not share values for one or more statistical categories. In that case, it would be impossible to edit and save them all at once. I have attached a screenshot for illustration.

[Kathy Lussier (klussier)]

I've confirmed everything Beth reported in her comment. FWIW, the same behavior previously existed when performing batch edits from the Copy Bucket in the web client.

I have a few comments to add for number 2. It took me a few minutes to replicate what Beth was seeing. To replicate, select multiple items that do not share the same price from item status and then select the action to edit them. Once in the copy editor, deselect most of those items so that only one is selected. A value for that one item will now appear in the price field. If you then reselect those other items to make a batch change, that value for the price remains in the field. This behavior differs from what happens with other fields that don't share the same values. In those cases, once you reselect the copies, the displayed values become blank again.

Although all of these issues should be addressed, I see #3 as being a critical issue that will prevent users from being able to batch edit items. As Beth said, it's fairly typical for staff to apply a batch edit to copies that do not share the same required statistical categories. In those cases, the user will be unable to make those batch edits.

[Robert J Jackson (rjackson-deactivatedaccount)]

Just received report of (and confirmed) that when using Item Status to delete items from Evergreen web client by selecting all and then using Action menu and Delete Items only one item is actually deleted.

The resulting display contains duplicate entries of the selected non-deleted rows along with a single entry for the actually deleted item. I scanned in 4 item barcodes, made sure they were all checked and from the action pull down menu I selected delete items.

I am attaching screen shots showing the progress:

delete_item_status1 -> shows the 4 items to be deleted all selected
delete_item_status2 -> shows popup for what I assume is the only row deleted
delete_item_status3 -> shows the end results on the Item Status screen
delete_item_status4 -> shows verification of the one deleted item
delete_item_status5 -> shows item status screen with a fresh rescan of the items not deleted

[Kathy Lussier (klussier)]

Hi Robert,
I would file a new bug on that issue since I consider it to be different than the batch-editing bug. This bug is related to the fact that the copies are retrieved in the copy editor in such a way (i.e. in multiple tabs) that batch edits cannot be made to them. The batch deletion should just work without any invocation of the copy editor.

If you file the new bug, I'll be happy to confirm since I did check it out before posting my comment.

Also, once the maintenance release is out later today, I plan to sign off and merge Cesar's branch for the fix to open the copies in one tab since that fix is working as described. I'll create new bugs for the issues Beth discovered in her testing.

[Robert J Jackson (rjackson-deactivatedaccount)]

Thanks for the input/reply Kathy. I have created a new bug as suggested: 1735539

[Jason Etheridge (phasefx)]

I think we should open new bugs for Beth's issues as well and go ahead and push this one. What do folks think? Since the bugs are in the editor code and not the invoking code, and can be triggered elsewhere.

[Andrea Neiman (aneiman)]

+1 to creating Beth's issues as new bugs. If no one else gets to it by this afternoon I'll take care of that.

[Andrea Neiman (aneiman)]

Filed issue #1 at bug 1738890
Filed issue #3 at bug 1738893

I was unable to replicated issue #2 at this time so I did not file that.

[Kathy Lussier (klussier)]

Adding a note that I am no longer able to replicate #2 either.

[Kathy Lussier (klussier)]

Thank you Cesar, Beth, Jason and Andrea! I've signed off on the patch and merged it to master and release 3.0. I didn't backport further due to conflicts in release 2.12.