Funky progress bar behavior on View Holds screen
Bug #1717007 reported by
Kathy Lussier
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Evergreen version: 2.12.5 and 3.0beta
The progress bar on the bib record page's View Holds tab will hang in the following situations:
1. When there are holds on the record, but no holds that fall within the context OU pickup library location. If you then click to expand the list to the Consortium, the holds will be successfully retrieved.
2. If you select a hold, click Detail View, and then click to return to List View, the progress bar will hang.
In both cases, I see the following in the Console - https:/
A screencast showing this behavior is available at https:/
description: | updated |
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
status: | New → Confirmed |
Changed in evergreen: | |
milestone: | 3.0.0 → 3.0.1 |
tags: | added: signedoff |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Progress bar fix pushed:
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ berick/ lp1717007- funky-hold- progress
This commit makes the progress dialog smarter about resolving multiple simultaneous open calls. Specifically, it plugs up a race condition that allowed multiple modal instances to be open with only one of them getting closed.
=
Note, however, this only fixes the dialog quirk. The source of the problem noted in this bug is that the holds-for-record grid is rendered twice in quick succession when navigating back from the detail view.
I experimented with disabling the eg-org-selector onchange handler to see if that was the cause (based on bug #1685356), but in this case the onchange is firing in the midst of an active grid refresh (the 2nd one), so it's essentially ignored, because the grid only allows one active refresh at a time.
More research is needed here, since rendering the grid twice could be problematic in other ways. I have a vague memory of this being discussed in another bug, but can't find it now.