webclient: Stop sign alert should only display when retrieving patron

Bug #1635407 reported by Kathy Lussier
This bug affects 2 people
Affects Status Importance Assigned to Milestone

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.

Revision history for this message
Bill Erickson (berick) wrote :

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.

Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

Above described code implemented here:


To recap, each browser tab tracks its last alerted patron. Once the alert pane has displayed for a given patron, it will not show again for that patron until another patron is loaded, resetting the last-alerted value, or the patron is loaded into a new browser tab.

tags: added: pullrequest
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
status: New → Confirmed
milestone: none → 2.next
Revision history for this message
Kathy Lussier (klussier) wrote :

Hi Bill,

I'm seeing that the patron's id is populating the eg.circ.last_alerted key when the patron is retrieved, even if an alert didn't appear for that patron. Is that expected? I'm not necessarily opposed, since, the alerts generally are most useful when the patron is first retrieved. But I just wanted to check the underlying assumptions before signing off.

Everything else looks good!

Revision history for this message
Bill Erickson (berick) wrote :

Hi Kathy, yes, that was my intention. My thinking was the alerts should reset with every new patron view/load, regardless of whether the currently viewed patron has alerts.

Revision history for this message
Kathy Lussier (klussier) wrote :

Excellent. I agree. I've signed off on the code and merged it with the sprint4 collab branch.

Thanks Bill!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
milestone: 2.next → 2.12-beta
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.

Other bug subscribers