webstaff UX: default hold notification preferences for patrons confusingly presented

Bug #1774268 reported by Galen Charlton on 2018-05-30
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.0
Undecided
Unassigned
3.1
Undecided
Unassigned
3.2
Undecided
Unassigned

Bug Description

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 on the patron registration form in XUL reflected end result behavior while in the web staff client, the checkboxes just represent the state of the user setting.

Evergreen 3.0+

Galen Charlton (gmc) on 2018-05-30
tags: added: holds usability webstaffclient
description: updated
Jason Stephenson (jstephenson) wrote :

I've noticed also that patrons edited or created in the web staff client get entries in opac.hold_notify of an empty string if these are not set. I do not recall seeing that with the XUL client.

Changed in evergreen:
status: New → Confirmed
a. bellenir (abellenir) wrote :

users with empty strings for opac.hold_notify in actor.usr_setting seem to be problematic. when attempting to place a hold for one such user, i got javascript errors in the browser:

SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at JSON2js (JSON_v1.js:9)
    at eframe.js:249
    at u (vendor.bundle.js:6)
    at vendor.bundle.js:6
    at h.$digest (vendor.bundle.js:6)
    at vendor.bundle.js:6
    at r (vendor.bundle.js:6)
    at vendor.bundle.js:6 "Possibly unhandled rejection: {}"

i'll consider that a separate issue for now.

as for this bug, with the patron settings editor, how's this?

* specify a default hold notify of ':phone:email' (maybe someday make this a configurable setting)
* use the default user preference if the actual user preference is falsey (null or empty string)
* always prefix the saved preference with a ':' so that a user that specifies no contact as their preference will not fallback to default (do not save an empty string.)
* skip saving a value for the preference if begins at and remains the default

here's a branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=21e0315bcbecaeaae862a28a1ef9893f6169321f

tags: added: pullrequest
tji@sitka.bclibraries.ca (tji) wrote :

* specify a default hold notify of ':phone:email' (maybe someday make this a configurable setting)

The default value could be set up via User Setting Type. We set them up with phone:email to tackle the issue caused by BiblioCommons (affecting only a few libraries), which does not set up phone_notify or email_notify in hold records if opac_hold_notify is not present.

Now on the web client, changing the default value seems having no effect on Patron registration screen.

I like to have the old behaviour on XUL back. Without the presence of opac_hold_notify, display both phone and email selected on patron edit/registration and in My Account. (BTW, these two checkboxes are still selected on Place Hold screen.)

Now this new behaviour on the web client is causing confusion (not knowing patron's choice is going with default of both email and phone or not being notified at all), and trouble when editing patron account (an entry for opac_hold_notify with "" is created).

Tina Ji
BC Libraries Coop

Rogan Hamby (rogan-hamby) wrote :

Patched tested and signed off on here: user/rogan/lp1774268signoff

tags: added: signedoff
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
Changed in evergreen:
milestone: none → 3.3-beta1
Changed in evergreen:
assignee: nobody → John Amundson (jamundson)
John Amundson (jamundson) wrote :

I have tested this patch on a 3.2 system, and I'm seeing a couple issues with it.

* specify a default hold notify of ':phone:email' (maybe someday make this a configurable setting)
In my testing, registering a patron without changing notify preferences did not create a user setting for the patron. This was how the XUL client behaved. LP bug #1361258 sought to fix this by creating a default setting of "phone:email" for a patron created in the web client.

Adding the default setting was an improvement in a couple different fronts, including the OPAC, (see Full Testing below). There is also a community mobile app or two out there that only recognizes preferences if they exist in user settings.

Changes made in the OPAC to preferences are also not correctly reflected. If preferences are removed here, the setting is updated to an empty string, which the web client Edit screen now sees as phone/email notify but the Place Hold screen sees as "Do not notify".

Here are my thoughts after testing:
The current web client behavior works well for accounts created in the web client. The only issue comes from accounts created in the XUL client, but as the XUL client is deprecated in 3.2, perhaps a temporary solution of running a script to add user settings for opac.hold_notify of "phone:email" where they do not exist would be better.

Or, perhaps there would be a way to simply allow the web client Edit screen to translate a user with no hold notify settings as checkmarks for phone/email.

Here's my full testing:

Creating patron account in web client with default settings left:
- no user setting is added in database
- phone, email checked by default when placing a hold in web/xul/opac

Creating patron account in xul client with default settings left:
- no user setting is added in database
- phone, email checked by default when placing a hold in web/xul/opac

Updating default notify patron record in OPAC to remove all notify preferences:
- preferences screen shows email/phone not checked even though still set to default. Simply saving the screen does NOT update settings. Settings must be checked, saved, unchecked, and saved again to update...
- user setting updated to ""
- phone, email not checked by default when placing a hold in web/xul/opac

Updating patron record in web client to remove all notify preferences:
- user setting updated to ":"
- phone, email not checked by default when placing a hold in web/xul/opac

Updating patron record in xul client to remove all notify preferences:
- user setting updated to ":"
- phone, email not checked by default when placing a hold in web/xul/opac

EXTRA PROBLEM:
- when a patron record with an empty string, "", is opened in the web client, phone/email show checked by default on Edit screen even though this is reflected as a "don't notify" on the Place Hold screen
- saving the edit screen without making any changes keeps the empty string setting.

Changed in evergreen:
assignee: John Amundson (jamundson) → nobody
tji@sitka.bclibraries.ca (tji) wrote :

I tested on 3.1.7.

I can confirm the above issues:

1. deselecting all checkboxes from Patron Edit and My Account adds different values in the usr_setting entry: ":" from Patron > Edit; "" from My Account

2. entry with "" in usr_setting is not correctly reflected as none checkbox being selected on Patron > Edit

If ":" is preferred for not_to_notify choice, the old value of "" needs to be taken care of.

Additional related findings:

If opac_hold_notify usr_setting_type has no default value, no entry is created for newly created patrons, though both email and phone checkboxes appear selected on Patron Registration/Edit/Place Hold/My Account.

If "phone:email" is set as the registration default in the usr_setting_type, you will see the same behaviour, but there is an entry with value of ":phone:email" created on patron registration.

This is XUL behaviour, too. We use the default value to force creating the usr_setting entry.

Tina Ji
BC Libraries Coop

Dan Wells (dbw2) on 2019-02-06
Changed in evergreen:
importance: Undecided → Medium
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Chris Sharp (chrissharp123) wrote :

Removed signedoff tag since two testers have found issues.

tags: removed: signedoff
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Michele Morgan (mmorgan) on 2019-04-18
tags: added: needsrepatch
tags: removed: pullrequest
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers