Wishlist: Make Preferred Name variables easier to use

[Michele Morgan]

Evergreen 3.2

The Preferred Name variables used in print templates and action triggers should return the preferred version of the name field, if one exists, otherwise the primary version of the name field should be returned.

Currently, when using the following variables in print templates and action triggers:

pref_prefix
pref_first_given_name
pref_second_given_name
pref_family_name
pref_suffix

if there is no value for the preferred name element, nothing is returned, so conditional code must be used to return the primary name if there is no preferred element. An example of conditional code that is needed for print list templates provided on the mailing list by John Amundson is:

<span ng-if="patron.pref_family_name">{{patron.pref_family_name}},</span>
<span ng-if="!patron.pref_family_name">{{patron.family_name}},</span>
<span ng-if="patron.pref_first_given_name">{{patron.pref_first_given_name}}</span>
<span ng-if="!patron.pref_first_given_name">{{patron.first_given_name}}</span>

Similarly, conditional code is also needed to make use of the preferred names in action trigger templates.

With this proposed change, configure print templates and action triggers would be much simpler.

Should there be a need for the patron's full legal name, the following would still provide those name elements:

prefix
first_given_name
second_given_name
family_name
suffix

Relevant IRC discussion:

http://irc.evergreen-ils.org/evergreen/2019-09-05#i_418031

Relevant email thread:

https://georgialibraries.markmail.org/thread/mk7vjpqcqijrs235

[Jeff Davis (jdavis-sitka)]

It would be really nice if this could be done via the IDL for consistency across many different uses, not just in print templates or triggers.

[Ryan Eby (aadl-ubuntu)]

I'm not sure the best solution, but this is a growing issue across the code base and interfaces. We similarly need the booking pull list to pull the preferred name if it exists.

I'm not sure on performance, but maybe there needs to be generated columns on actor.usr that coalesce the fields into an authoritative column. Then all interfaces can use that field without duplicating the conditional if statements or their own coalesce (like hold shelf).

[Bill Erickson (berick)]

Mentioning this in case it helps: we are in the process of swapping the two name varieties to avoid all the code/template changes needed to show the preferred name.

All existing name data (actor.usr.family_name, etc.) will be treated as the preferred name going forward. The new preferred name fields will be relabeled as "Legal Name" fields and only used when they differ from the base/preferred name, and only displayed in cases where it's needed, which, as it turns out, is not very many places.

Code-wise, it entails a few label changes and swapping some data in the database.