Web client: Editing item information from the item status screen does not automatically update item status display

Bug #1721109 reported by Kathy Lussier on 2017-10-03
70
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Medium
Unassigned

Bug Description

In the xul client, if you edited an item from the item status list view, after saving changes, upon returning to the item status page, the client added a second line for this item showing the updated information for the copy.

In the web client, we return to the item status screen with no visible change to the previously-scanned item. If a field displaying in the grid was changed, the line continues to show the old value for that field rather than the new one.

I've heard two schools of thought about the old xul client's behavior. Some people didn't like that the client added the second line to the item status list. They thought it was confusing. Others thought it was a good way to see a comparison between the old scan and new scan.

In both schools of thought, users wanted to see the new, updated information after the changes were saved. The web client currently doesn't do so. The only way to see the new information is to scan the barcode again or to click to see the Detail View. Refreshing this screen does not work.

I think it would be good to have a discussion about whether we want a save to add a new line to the grid or if we just want it to update the item with the new values. Maybe a checkbox in the interface that determines the behavior is warranted.

Elaine Hardy (ehardy) wrote :

I see value in both approaches and could also see where there might be circumstances where a user would want the two lines and others where it wouldn't be necessary. I think a checkbox to control the behavior on the screen itself would be a great solution.

Changed in evergreen:
status: New → Confirmed
Kathy Lussier (klussier) on 2018-05-17
Changed in evergreen:
importance: Undecided → Medium
Jane Sandberg (sandbej) wrote :

We would prefer either:

1) Items in the item status screen just get updated, and do not receive duplicate rows, or
2) Items in the item status screen get a duplicate entry, but there is a clear visual cue as to what information is current, and which is up-to-date.

A checkbox seems like a nice solution too.

Janet Schrader (jschrader) wrote :

+1 to Jane's comment.
After our upgrade to web client 3.0, not being able to see changes in Item Status has been one of our biggest frustrations. Libraries report items not being edited when the edits have happened.

Jane Sandberg (sandbej) wrote :

Oops, I meant "what information is current, and which is out-of-date."

+1 to Jane & Janet's comments

We would prefer either:

1) Items in the item status screen just get updated, and do not receive duplicate rows, or
2) Items in the item status screen get a duplicate entry, but there is a clear visual cue as to what information is current, and which is up-to-date.

Since upgrading to 3.1 Not being able to see changes in Item Status has been a big frustration for us as well

Jennifer Weston (jweston) wrote :

+ 1 to Jane & others

Since upgrading to 3.1.6 not being able to see changes in Item Status is frustrating for all users.

We echo the preferences documented by others:

1) Items in the item status screen just get updated, and do not receive duplicate rows, or
2) Items in the item status screen get a duplicate entry, but there is a clear visual cue to identify the changes

A checkbox to control the behavior would work nicely.

Jane Sandberg (sandbej) wrote :

I'm going to try a BroadcastChannel-based solution to this for bug squashing week (inspired by Cesar's work here: https://bugs.launchpad.net/evergreen/+bug/1684202).

As far as UI goes, I'm going to try solution #1 (Items in the item status screen just get updated, and do not receive duplicate rows). I'm also going to add a status column that adds a "Saved" icon when changes have been made to an item in another tab.

Changed in evergreen:
assignee: nobody → Jane Sandberg (sandbej)
Jane Sandberg (sandbej) wrote :

Here's a new branch: user/sandbergja/lp1721109_update_item_status_after_holdings_changed

And here's a link to it: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1721109_update_item_status_after_holdings_changed

In addition to showing newly updated data in the item status grid, this also adds:
* a toast message to let the user know that their changes have been saved, and
* a status column with a little icon that shows which rows have been modified.

Here are the testing notes from the commit message:

1) Go to Item Status List View, select an item, and go to Actions >
Edit > Items (or Call Numbers, or both).
2) Make a change to one of the columns you have active in
the Item Status list view. Click Save and Exit.
3) Note that the list view of Item Status has not updated.
4) Load this commit.
5) Repeat steps 1-2.
6) Note that the columns are updated this time. Note that
there is a new status column, and that an icon appears for
all the rows that you have changed. Also, note that there
is a toast message in the bottom right hand corner of the
screen confirming that you have successfully made your change.

Changed in evergreen:
assignee: Jane Sandberg (sandbej) → nobody
tags: added: cataloging pullrequest
Jane Sandberg (sandbej) wrote :

Just a note that I'd messed up handling some of the promises, so I force-pushed a fix to that same branch. :-)

Michele Morgan (mmorgan) on 2019-03-07
Changed in evergreen:
milestone: none → 3.3-rc
Chris Sharp (chrissharp123) wrote :

I see this working as advertised. Pushed to master and rel_3_2. Thanks, Jane!

Changed in evergreen:
status: Confirmed → Fix Committed
tags: added: signedoff
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers