Required Fields Based on Hold Notification Preferences Too Strict

[Michele Morgan]

Evergreen 3.5

Bug 1570072 introduced some required fields based on the user preferences for hold notification on the patron registration screen that are too strict.

Staff can select patron notification checkboxes for phone, email, and SMS (if enabled) on the registration/edit screen.

The 3.5 registration screen requires that:

- if phone notification is checked, the default phone user setting field is required
- if email notification is checked, the email address field in the patron record is required
- if SMS notification is checked, the Default SMS/Text Number is required, when the number is filled in the carrier becomes required

The SMS requirement is an improvement, but issues with the phone and email preferences are:

1. The Default Phone Number user setting is not required when phone notification is selected. Without the user setting, the patron's Day Phone is used for notification

2. Prior to 3.5 it has been possible for patron to have email as a notification preference, but no email address. The Place Hold screen handles the mismatch. When placing a hold, email notification will be set to FALSE

To streamline patron creation and updates, it should be possible to save the patron record when the email field and Default Phone Number user preference are not set, but the phone and email notification preferences are set.

[Terran McCanna (tmccanna)]

I am confirming the problem with the Default Phone Number. If Phone is checked as the default hold notification preference and there is no Default Phone Number entered, it should still save as long as there is a Daytime Phone. It shouldn't be necessary for staff to have to enter the phone number twice if they are the same number (which they *usually* are).

Although I see the point about the email address, I don't necessarily agree. I think if Email is selected as a hold notification preference default, it should require the email address to be stored. We use the email address for a lot of different types of notifications other than hold notices, but if a patron really doesn't want it to be stored in their record and receive those other notices, they still have the option of checking the email box and entering their email address at the time of hold placement.

[John Amundson (jamundson)]

I would swear I have a distinct memory of testing this in its early days, documenting this issue, and having the behavior updated to look at the day time phone number, but something must have changed between my testing and when it was committed to Evergreen.

The Phone Notify checkbox really should pay attention to the daytime phone number. Its current behavior will most likely become annoying very quickly when we go up on 3.5+. We have many patrons with phone notify set and just a daytime phone number.

I do not have a strong opinion on the email behavior one way or another, though I lean towards Terran's reasoning.

[Jennifer Bruch (jbruchpails)]

This makes me think that the notification settings need to be less default and more intentional.

So instead of phone and email methods being selected by default, they are only selected if certain fields are filled in during the registration process.

Example:
Daytime phone being filled in prompts the copying of information to the default phone number field and selection of the phone notification box.
Email field prompts the selection of the email notification box.
Filling the SMS info prompts the selection of the SMS notification box. (Way to test SMS notice at this point would be great, few patrons really know the carrier and make guesses.)

We have a Library Setting to use the last 4 digits of the daytime phone for the PIN. This setting could a starting point to creating a setting that takes the daytime phone and inserts it into the default phone number field?

[Elizabeth Davis (elidavis)]

It seems to still be an issue in 3.7 and in our test 3.9 instance.

[Garry Collum (gcollum)]

Just to add a note to Jennifer's "less default" comment. We set the Registration Default of the opac.hold_notify user setting type to "".

After this is set none of the check boxes for hold notify are checked in the registration screen.

[Elizabeth Davis (elidavis)]

Something one of our libraries has noticed with this bug is when invalidating a patron's email address, we are forced to uncheck the Holds Notice box for email to get it to save. This loses the preference, and staff are adding an alert to remind themselves to add the preference back. We have noticed that if we don't hit save, the invalid email function saves on its own.

[Elizabeth Davis (elidavis)]

Would this be something that could be set at the org unit level via a library setting? I know some of our libraries would like to require the default hold notification methods, while others would not.

[Josh Stompro (u-launchpad-stompro-org)]

Just a wanted to chime in that we have also found this new behavior to be extremely painful. This has resulted in a lot of customer complaints because of missed notifications.

It throws away all the fall through preferences logic. The Angular catalog place holds interface tries to use the day phone and then the evening phone for the phone notify for the default phone notify number. (Although there is a bug 2073896 with that).

We locally had setup the sms number to also use the day phone number as the default if the sms number preference wasn't set.

Like others have said, when invalidating email this causes the patron record to no longer be savable. Which results in us loosing the customers preference for notification if the box isn't re-checked when a new email or phone is received from the patron.

The notification preferences should not be tied to the existence of a number/email. One is an intention, the other is a specific address. And the proliferation of fields to hold phone numbers in the case where the customer just has one number causes problems whenever an account needs to be updated with a new number. We see a lot of instances where only one field gets updated, and staff miss that their are 3 duplicate fields that all need to be updated in the case of day phone, opac default phone and sms phone all being the same.

I think I understand why Bug 1570072 did this though. It simplifies the logic to check for phone number changes when trying to update existing holds.

Here is a working branch that just removes the required attributes from the Email, Default Phone and SMS Phone fields in the patron editor. This is a quick way to get rid of the problematic behavior. But doesn't address how this will effect the behavior of updating existing holds on changes, I haven't tested that yet. I'm not going to mark this as pullrequest since this is just a quick work around.

Working branch: user/stompro/lp1901726_patron_notification_preference_required_fix

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