Patron preferred name display can cause duplicates

Bug #1792482 reported by Bill Erickson on 2018-09-14
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

Evergreen 3.2-beta1

Use case in question is when a patron uses their middle name as their preferred first name. In the current display, where preferred names simply override primary names, this can result in names where the first and middle name are the same. E.g. Albert John Smith becomes John John Smith.

Proposed solution is to only show preferred prefix, middle, and suffix fields when a preferred value is applied. As before, we always show a first and last name, where the preferred name acts as an override.

With this approach, Albert John Smith displays as John Smith when no preferred middle name is set.

Bill Erickson (berick) wrote :

The solution of only displaying certain preferred name fields when values exist works well in the staff client, because there are dedicated slots in the UI for primary and preferred name. In the catalog, though, we just display one name value in the account preferences page.

I'd like to avoid checking the values of the names (e.g. does first name equal middle name), so I propose we add a dedicated preferred name field to the account settings page in the catalog, visible only when a preferred name is present, using the same display logic as in the staff client. That way the source of the values is always apparent.

Bill Erickson (berick) wrote :

Branch with 2 commits pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1792482-patron-pref-less-middle

1. Only display middle name values in the patron preferred name fields when a preferred middle name value exists.

2. Adds a new Preferred Name field to the catalog account preferences page, using the same display logic as the staff client.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: added: pullrequest
tags: added: opac
Kathy Lussier (klussier) wrote :

Thanks Bill! It works as described for me. Merged to master for inclusion in the 3.2 RC.

Changed in evergreen:
status: New → Fix Committed
importance: Undecided → Medium
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers