Item Status Order Changes After Updates

Bug #1820887 reported by Robert J Jackson
58
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

Evergreen 3.2

Once items are updated using the Show in catalog function the New Status Saved! icon appears next to the ones Saved. However, Once Item Status refreshes itself from the saves it tends to not refresh the list in the order in which the items were originally scanned in. This is a problem if you're going down a list of items to edit and suddenly the list is out of order from what you were using. The save icons help somewhat to mitigate this issue but it is still a disruption to how we've come to expect item status to work, especially if the scanned order was important in some way.

On the attached file (scanned from Chrome), the save icons are the first three items that were on the list when it was scanned in, but now as you can see the list has been shuffled up. There does not seem to be any rhyme or reason to how it has reshuffled the list from what I can tell.

This problem has been happening since the Status column was added last week or so.

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :
Elaine Hardy (ehardy)
tags: added: cataloging
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Thanks for reporting this. I can't confirm this on Chromium. Is this only happening in Firefox?

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

According to the reporting library it was Chrome.

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

From Reporting library:

"Tested it again in Chrome. I opened a bunch of items in the catalog, saved the items like I'd just edited them, and waited for Item Status to refresh them. I marked the rough order this time between the two screenshots.

I've only tested it once in Chrome after encountering it a bunch in Firefox. I waited until I saw it in Chrome to submit the report."

Will post the two resulting screen shots Problem_001a.png and Problem_002a.png

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

Here is the promised second screen shot for #4 above.

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

I'm unable to replicate this in 3.3.3 in Chrome.

When I edit items using the Show in Catalog option (without doing any sorting on Item Status) the items stay in their original order every time Item Status refreshes.

If I sort by a column in Item Status and then update an item when the list refreshes the item will be moved in the list to be properly sorted (ie. if I sort by status and then change the status or by call number and then change the call number). I think this is desired behaviour as the item is moved so that the list is still properly sorted.

Revision history for this message
Janet Schrader (jschrader) wrote :

I think this is similar.

One of our catalogers reported that items scanned into item status did not display in order scanned. We think it has to do with the new refresh.
I can confirm that if I edit an item in the holdings editor and then within 10-15 seconds scan that barcode into item status, item status displays the "item successfully modified" icon in the far left status column even if the item was not edited in Item Status, even after 30 seconds or so I get the same edited icon. If I wait 60 seconds and scan the barcode into item status it does not display as an edited item.
I haven't determined the exact amount of time it takes the system to not see the edit as a new one, modified in item status, but it appears to be significant. However, I do not think that this way the item status refresh is supposed to work.

Chrome
Release 3.2.8

Elaine Hardy (ehardy)
Changed in evergreen:
status: New → Confirmed
tags: added: itemstatus
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.