Wishlist: Patron Alternate/Preferred Names

[Bill Erickson]

Provide a means to store a patron's former or preferred name, when it differs from their legal name, improving the ability for staff to find patron records when searching by patron name. This alternate name could be used for notices, in receipt templates, and/or as the name that displays when patrons log into the catalog.

Here's the original full project description: http://masslnc.org/node/3303

The goal of this bug is a little less ambitious and more closely follows the development plan laid out by EOLI in their design document, with some variations:

https://yeti.esilibrary.com/dev/public/techspecs/patron-names-optionA.pdf

General plan:

1. Create a secondary set of name fields (first, middle, last, prefix, etc.) that live on the user table in the database.

2. Additionally add a name keywords field that may contain any other name related data staff may want to search on the patron.

3. Modify the patron search to search both primary and alternate versions of each name field. E.g. searching last name will search both family_name and alt_family_name.

4. Add a name keyword search to the patron search API that searches all name fields and the new keyword field.

5. Add patron editor support for maintaining the new fields.

6. Add summary display in the patron sidebar when alt name data exists.

7. Add support to patron self-register app for adding alt name values.

8. Display alt name values in my account.

9. Make this data available in various receipt templates, action_trigger's, reports, etc.

This project is sponsored by MassLNC.

[Bill Erickson (berick)]

The key difference between the documentation noted above and the goal of this bug is that the new fields are to act solely as preferred name fields. Other / alternate names go into the new name keywords field. The existing name fields will retain their current meaning.

In certain contexts (notices, patron UI's), the preferred name will override the primary name when preferred name data is available. The other/alt name data will be used for staff searching only, not for display.

[Bill Erickson (berick)]

Branch in progress:

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

[Bill Erickson (berick)]

Branch noted above finalized, squashed, and rebased to master. Including release notes.

[Kathy Lussier (klussier)]

Thanks Bill! MassLNC has tested the following features in this branch and confirmed that they all work as expected:

1. The preferred name and name keywords save as expected.
2. The preferred name displays in a logical manner in the patron summary sidebar and in the public catalog.
3. Print templates and action trigger notices can be configured to use preferred names, if one is present on the patron record. Preferred names are also available in reports.
4. Preferred names move to lead record during patron merge if no preferred name exists on the lead record. Name keywords move to the lead record and are deduplicated.
5. In patron search, first name now searches both primary and preferred first names, last name searches both primary and preferred last name, etc. Name Keywords searches all of these name fields, including the new name keywords fields. This new search field handles punctuation in the same way as the other patron search fields and also provides a left-anchored search.
6. Preferred name fields are available on the self-registration form.

I have added my signoff to the branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1776020-patron-pref-name-signoff

I have not yet merged it because I would like to give somebody who was uninvolved in the project a chance to review it.

Thanks again Bill! Our libraries are going to love this new feature!

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.2-beta. Thanks, Bill and Kathy!