webstaff UX: default hold notification preferences for patrons confusingly presented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
High
|
Unassigned | ||
3.0 |
Won't Fix
|
Undecided
|
Unassigned | ||
3.1 |
Won't Fix
|
Undecided
|
Unassigned | ||
3.2 |
Won't Fix
|
Undecided
|
Unassigned | ||
3.3 |
Fix Released
|
High
|
Unassigned | ||
3.5 |
Fix Released
|
High
|
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+
tags: | added: holds usability webstaffclient |
description: | updated |
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) |
Changed in evergreen: | |
importance: | Undecided → Medium |
Changed in evergreen: | |
milestone: | 3.3-beta1 → 3.3-rc |
Changed in evergreen: | |
milestone: | 3.3-rc → 3.3.1 |
tags: | added: needsrepatch |
tags: | removed: pullrequest |
Changed in evergreen: | |
milestone: | 3.3.1 → 3.3.2 |
Changed in evergreen: | |
milestone: | 3.3.2 → 3.3.3 |
tags: | added: pullrequest |
Changed in evergreen: | |
milestone: | 3.3.3 → 3.3.4 |
Changed in evergreen: | |
milestone: | 3.3.4 → 3.3.5 |
Changed in evergreen: | |
assignee: | nobody → Jason Etheridge (phasefx) |
Changed in evergreen: | |
milestone: | 3.3.5 → 3.4.2 |
Changed in evergreen: | |
milestone: | 3.4.2 → 3.4.3 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Changed in evergreen: | |
assignee: | Jason Etheridge (phasefx) → nobody |
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.