Comment 0 for bug 1774268

Here's a situation; using bullet points to describe it for (hopefully) clarity:

* If a patron has a value set for the opac.hold_notify user setting (including the empty string), that value governs which notification checkboxes are selected on the OPAC place hold form.
* If they do not have a value set for that user setting, the OPAC place hold form will default to checking the phone and email notification boxes.
* In the XUL patron editor (when editing an existing patron), if the patron has a value set for that user setting, that governs which notification methods are checked on the registration form.
* In the XUL patron editor (when editing an existing patron), if the patron does NOT have a value set, the registration form defaults to checking the email and phone boxes, matching what the OPAC would do for the place hold form.
* The XUL patron editor did not always save values for opac.hold_notify when registering a new patron.
* Migrated patron records are not guaranteed to have opac.hold_notify set.

And here's the kicker:

* The web staff client's patron registration form (when editing an existing patron) will /always/ reflect the value, or not, of the user setting; it will NOT check the phone and email boxes if the user setting is not present.

This has led to usability confusion for at least one library, where the state of the checkboxes as reflected on the patron registration form in XUL reflected end result behavior while in the web staff client, the behavior represented the state of the user setting.

Evergreen 3.0+