webclient: Stop sign alert should only display when retrieving patron
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Low
|
Unassigned |
Bug Description
The stop sign that appears with patron alerts should only display when first retrieving a patron.
However, in the web client, it sometimes appears at other times when working in the patron record, causing an annoying alert to appear when unexpected that staff need to click through before proceeding with their work.
One series of steps that will cause this to happen:
Retrieve a record for a patron that had items out. Click through any stop sign alerts that may appear for this patron.
Mark one of the items lost.
Now click the Bills tab so that you can see the bill that was just generated.
If the bill was large enough to trigger an alert, the Stop Sign alert page will appear at this point. The user then has to click the Bills tab again to view the bills page.
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
milestone: | 2.next → 2.12-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
The code tries to remember if an alert page for a patron has been displayed, but there are cases (when navigating away and back to the patron app) where that information is reset. We could improve tracking by adding a storage value for the ID of the user for which the alert pane was last shown.
For this, it may make sense to use a sessionStorage value (hatch. setSessionItem( )). That would guarantee alerts won't repeat per browser tab and the value would automatically clear as each tab is closed (so they don't come back to bite us). Alternatively, we could use a LoginSession item, which would be cross-tab, but I'm wary of piling on too many browser cookies.