Wishlist: Ask to Confirm Holds Placement When No Notifications Are Selected

[Brett French]

Similar to the warnings that pop up in order to prevent patrons from accidentally deleting lists or paying bills, it may be helpful if patrons are given an alert asking them to confirm that they'd like to place a hold without choosing any of the options to be notified when the pickup is ready?

Currently, when a hold is placed and no notification preferences are selected, the system just places the hold. While it's certainly true that some users do not want to be contacted by their library when the hold arrives, we're seeing an increase in reports that patrons have de-selected all notification settings when they place their holds, then are upset that they're not being notified that the holds are in.

A pop up that warns users, "If you place this hold without selecting a notification option, you will not be notified of its arrival." (or something similar) when patrons attempt to place a hold without selecting a notification setting could be helpful in clearing up some of the issues.

Thanks
Brett

[Terran McCanna (tmccanna)]

I could have sworn there was already a wish list for this, but I couldn't find it if there is.

[Steven Mayo (stmayo)]

PINES has had a customization for this in place for a while. It uses a browser alert, which may not be the slickest (or accessible?), but I'll make it available in case it's useful. We discussed whether this would need to use a library setting in case a consortium didn't want the alert (maybe they can't support any notifications?), but for now decided to just make it available.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/smayo/lp2002572-Add_Warning_No_Hold_Notification

[Terran McCanna (tmccanna)]

Added pullrequest to get attention from testers / reviewers.

[Gina Monti (gmonti90)]

I, Gina Monti, sign off on this bug. A web browser notification appears to select a way to notify the patron for holds when nothing is selected. <email address hidden>

[Jane Sandberg (sandbergja)]

Thanks, Terran, Steven, and Gina. This works well with a mouse, and it is announced as expected in voiceover. However, there is a subtle issue when somebody is using keyboard navigation:

1. Find a record in the catalog
2. Press the place hold button
3. Tab to any selected notification options. Uncheck them using the space bar.
4. Tab to the Submit button.
5. Press enter.
6. Think to yourself: "thanks alert! I do want to add a notification option"
7. Shift-Tab so that the Cancel button has focus.
8. Press enter.
9. Note that the form has submitted, even though you pressed cancel. :-(

I noticed this in both Firefox and Edge.

[Terran McCanna (tmccanna)]

Removing signoff per comment #5

[Steven Mayo (stmayo)]

Thanks for the testing, Jane! I'm having trouble recreating the problem you mentioned.

When I use keyboard navigation on Firefox, Edge, or Chrome and press enter while the submit button is focused and then enter while the notification cancel button is focused, my form is not submitting. I've tried using the spacebar on submit and cancel, I've tried enter while NOT focused on the submit button but still in the form, I've tried different accounts - no bad submissions.
I even tried disabling javascript in firefox; the alert did not appear at all.

Are testing you on the mobius bugsquashing test server? Could this be browser versioning? Could it be a result of some plugin? Could this be specific to apple? Have you cleared your cache?

[Jane Sandberg (sandbergja)]

Definitely it was related to apple. It happened in Safari, Edge, and Firefox on MacOs with keyboard support. But in Fedora and Windows, the popup worked as expected, as we confirmed in the collaborative code review today.

[Michele Morgan (mmorgan)]

Pushed to main after reviewed at Monday's Code Review.

Thanks Terran, Steven, Gina, and all!