webclient: Stop sign alert should only display when retrieving patron

[Kathy Lussier]

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.

[Bill Erickson (berick)]

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)]

Above described code implemented here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1635407-webstaff-patron-alert-once

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.

[Kathy Lussier (klussier)]

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!

[Bill Erickson (berick)]

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.

[Kathy Lussier (klussier)]

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

Thanks Bill!