Inactive Barcode Alert Doesn't Consistently Display in Web Client

[John Yorio]

Evergreen 3.0.3

I'm not sure if this is a possible bug or more of a possible enhancement.

Here's the steps to reproduce:
In the web client, use an inactive barcode to retrieve a patron with no standing penalties or other alerts.

The first time you'll go to the /alerts page:
"Patron account retrieved with an INACTIVE card. Press a navigation button above (for example, Check Out) to clear this alert."

Repeat the search with the same, or a different, inactive barcode for the same patron: no alert.

I expected to see the alert each time.

Clearing the browser cache brings the alert back.

In the XUL client, when searching for a patron using an inactive barcode, the alert comes up as expected even with successive searches of the same inactive barcode.

It seems like it would be helpful if the web client behaved the same way.

[Mike Rylander (mrylander)]

John, does this still happen if you search for and load a different user between the two searches for the same user via an inactive barcode? Does simply hard-refreshing (shift-reload) the page between the searches make the alert work as expected? If those are true, I suspect this is happening because the user object and state info are cached in (probably) the patron service, so the alert page is marked as already "seen" for the current user. If that's the case, I'm not surprised that the alert doesn't show on the second search+selection of the same user with an alert. And, if that's the case, I'm not sure that's a bug since the client has already alerted the staff to the, um, alert. I'd think of that as an enhancement over the XUL version, but would like to hear front-line opinions!

[John Yorio (jyorio)]

Mike,

It does come up if you go to a different patron's barcode in between. Hard refreshing doesn't seem to make a difference, but I think that's because once you're on the patron's account without the alert, you're not on the alerts page.

So, it seems limited to this particular situation.

[Scott Thomas (scott-thomas-9)]

Mike and John,
    The most common reason why a barcode appears as Inactive is because it was lost. Though far less common, sometimes patrons report a library card stolen. In both cases staff needs to know immediately if someone tries to use the older barcode so this particular alert is on par with a Blocked alert in terms of importance. It needs to appear immediately when the record is retrieved.

[Dawn Dale (ddale)]

This may be a separate request but holds can be placed with an inactive card without any notification. Staff would like to see an alert when an inactive card is used anytime.

Thanks,

[Kathy Lussier (klussier)]

Dawn,

I would recommend filing that request in a separate bug report.

[Kathy Lussier (klussier)]

Mike's explanation in comment #1 matches up with the behavior I've seen for various alerts in the web client, not just the inactive barcode alert. I think it makes sense for the alert to only show when you first retrieve the patron and not show again unless you've moved on to another patron and returned.

In the case of the inactive barcode, in the xul client, if you retrieved the patron with an inactive barcode, the checkout barcode entry box was disabled. IOW, you were not allowed to perform a check out on a card that is marked inactive. Circ staff either needed to edit the patron record to mark the barcode as active to perform the checkout or they needed to retrieve the patron by some other means.

I would like to see similar behavior in the web client. It allows us to prevent checkouts from occurring on the inactive barcode without changing the current alert behavior.

[Dawn Dale (ddale)]

Thanks, Kathy. I have opened a new bug #1783151

[Robert J Jackson (rjackson-deactivatedaccount)]

Issue still present on latest release

[April Durrence (april-durrence)]

We are currently using 3.1.6 and had a question about retrieving a patron account with two different barcodes from a recently migrated library. When I tested in the web client, I was able to retrieve the account with the inactive barcode (both by patron search and using the checkout function) without any alert message displaying in either case. The checkout entry box was active for checkout, so there was absolutely no indication that the account was retrieved with an inactive barcode.

This does not replicate the behavior in the XUL client, as other have noted. In XUL, there is an alert message and the checkout entry box is grayed out and not usable.

There are good discussions of the reasons for maintaining a record of inactive barcodes in the patron account while notifying staff that the barcode may be in possession of an unauthorized person here: http://masslnc.org/node/2985 and here: https://bugs.launchpad.net/evergreen/+bug/1154235

[Erica Rohlfs (erohlfs)]

Noting that, in version 3.7, I'm not automatically taken to the alert/message at all. I need to always click Other > Display Alerts and Messages

[Lindsay Stratton (lstratton)]

Like comment #6, I would prefer that a lost/replaced card would either:

1 - NOT retrieve the record at all

Or

2 - If an account is retrieved, all transactions are blocked

The ability for lost/replaced cards to be used for circ, and access a patron's account information, could be a security and privacy risk.

I would like to see lost/replaced cards handled in the same way as merged records, with library settings that allow to delete the address, delete the barcode, deactivate the card.

[Michele Morgan (mmorgan)]

There was some recent confusion around this behavior from one of our libraries. We're on 3.7.2, and this is what we're seeing:

- Initially retrieving a patron with an intactive barcode shows the "Patron account retrieved with an INACTIVE card" message. The barcode entry box on the Checkout screen is greyed out.

- Retrieving the patron a second time with an inactive barcode does not show the INACTIVE card message. The barcode entry box on the Checkout screen is greyed out.

- Loading a different patron prior to retrieving the patron with the inactive barcode will again produce the message.

In our case, it would certainly have avoided a lot of confusion if the "Patron account retrieved with an INACTIVE card" message always appeared when the inactive barcode was scanned, regardless of whether the patron had been previously retrieved.

A related bug:

bug 1917761 - Add Ability to View, Edit, Delete All Patron Barcodes

[Terran McCanna (tmccanna)]

Adding my voice to those who would like it to be harder for actions to be taken on an inactive card. Maybe instead of just showing the initial alert message the first time the patron is retrieved, 1) make that message appear every time it is retrieved and 2) Make the user click through a "Do you want to open this user's current account?" acknowledgement.

[Jennifer Pringle (jpringle-u)]

+1 to Terran's suggestions.