Holds view does not refresh when navigating through search results

Bug #1792188 reported by Michele Morgan
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
3.2
Fix Released
Medium
Unassigned

Bug Description

Evergreen 3.2beta

When viewing Holds view on a list of search results in the web client, the list of holds does not refresh when using the previous/next navigation through the list of search results.

To reproduce the problem on a concerto database:

Search the catalog for 'harry'
Select first record and choose Holds View - one hold exists for pickup at BM1
Select Next to move to the next record in the search results
Note that the hold list still shows the hold list from the first title

This behavior does not occur on a community server running 3.1.4, when navigating through the search hit list in Holds View, the hold list refreshes to match the displayed title.

Revision history for this message
Shula Link (slink-g) wrote :

Confirmed in 3.0.2

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Andrea Neiman (aneiman) wrote :

This should have been fixed back in 3.0-alpha on bug 1672421. I am not seeing this on 3.1.5 or on 3.2 beta (test server bugsquash.missourievergreen.org).

tags: added: webstaffclient
Revision history for this message
Michele Morgan (mmorgan) wrote :

Here's the commit for bug 1672421:

http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00faa720a8dd94c781c50d508189d719f7f7f0d0

The single line change in Open-ILS/web/js/ui/default/staff/cat/catalog/app.js was removed in this commit:

http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14af809466039334348ba38b8417fb462d57f55b

Not sure if it was accounted for elsewhere in the new code.

I observed the holds not refreshing on three systems, a MassLNC sandbox set up for squashing at mlnc1.noblenet.org, an inhouse test system that has been upgraded to 3.2beta1, and also a "master-ish" system Ben Shum kindly allowed me to test on.

Revision history for this message
Andrea Neiman (aneiman) wrote :

Thanks for the additional info, Michele. I'm not sure why I wasn't seeing it on Missouri's test environment, but I checked on a local "master-ish" and now I am seeing what you reported.

Revision history for this message
Mike Rylander (mrylander) wrote :
tags: added: pullrequest
Revision history for this message
John Yorio (jyorio) wrote :

Tested and worked for me. I consent to signing off on this patch with my name and email: John Yorio, <email address hidden>

tags: added: signedoff
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Galen Charlton (gmc)
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
importance: Undecided → Medium
tags: added: regression
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master, rel_3_3, and rel_3_2. This doesn't affect 3.1.x as far as I can tell. Thanks, Mike and John!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
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.