Empty string for preferred name/alias overrides legal name in wide hold data

[Jeff Davis]

EG 3.8.2+, 3.9.1+, 3.10-beta+, master

Thanks to the fix for bug 1838553, a patron's preferred name and alias are now available on the Hold Shelf and other places that use wide_hold_data. However, empty strings in these fields will override the legal name, causing the name fields to appear blank.

How to test:

1. Find a patron who has an item on the Hold Shelf.
2. Open the Patron Editor for that user.
3. Go to the Preferred Name tab. Type and then delete something in the Preferred Last Name field, leaving the field blank. Click Save.
4. Go to the Hold Shelf and show the User Display Name column. The patron's last name will appear blank, because their preferred last name is an empty string.

I think wide_hold_data should treat empty strings as if they were null for these fields. (The patron editor should probably also treat edited empty textboxes as null, rather than as empty strings, but that's a separate issue.)

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1996651-wide-hold-data-pref-name-or-alias-empty-string-as-null fixes the issue by using NULLIF to test for empty strings in the preferred name and alias fields:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1996651-wide-hold-data-pref-name-or-alias-empty-string-as-null

To test:

1. Find a patron who has an item on the Hold Shelf.
2. Set the patron's alias and preferred family name to ''.
3. Load the Hold Shelf. The "User Display Name" and "User Alias or Display Name" columns should show the patron's legal family name (i.e. the empty string is treated as null, so we fallback to the legal name for both columns).

[Benjamin Kalish (bkalish)]

Is this a bug or a feature? We have patrons with mononyms and being able to have an empty first or last name field would be great. That said, we do need a way to make a distinction between a deliberately blank field and a field that is empty because it is not meant to be set.

[Jeff Davis (jdavis-sitka)]

I'd call this a bug, since the current behavior is an unintended side effect of a prior fix. It's causing problems for the libraries in my consortium.

The fix only tests for an empty string. If you put whitespace (one or more spaces) in a preferred name field, the field will display as blank, so that would be a way to have deliberately blank name fields for mononyms. It's definitely not a perfect solution, but I feel like whitespace is a less ambiguous way of saying "this field intentionally left blank" than an empty string.

[Terran McCanna (tmccanna)]

We just encountered this situation with live data and definitely interpreted it as a bug (not a feature).

[Susan Morrison (smorrison425)]

I have tested this code and consent to signing off on it with my name, Susan Morrison, and my email address, <email address hidden>.

[Lindsay Stratton (lstratton)]

This is definitely a bug not a feature, very confusing to staff who encounter it when processing a hold shelf.

[Jessica Woolford (jwoolford)]

+1 to bug, not feature. This was just reported to us today. Blank strings are ignored for the name that displays on the record itself, and therefore should be ignored in areas of the software.

[Jane Sandberg (sandbergja)]

Thanks, Jeff and Susan! Merged to rel_3_9 and above.