Null vs blank in text fields in patron record

[[e-mail]]

EG 3.9

We just found out that text fields in patrons, e.g. preferred names, alias, etc., are set to null if you do not touch them when creating a patron record. They are set to blank if you remove an existing value from them.

Blank is treated as a valid value when being displayed in User Display Name column on Holds Shelf and Holds Pull List screens. So staff see a comma displayed in the User Display Name column or blank in User Alias column, when Alias is blank in the patron record. (This is how we found the problem).

We also noticed another issue on Holds Shelf screen.

User Display Name column displays preferred names, if exist. But User Alisa or Display Name column does not display preferred names when there is no alias, but preferred names.

Tina Ji

BC Libraries Coop

[Susan Morrison (smorrison425)]

On 3.9, I tested adding and removing preferred names and was not able to result in the User Display Name populating with just a comma on either the Holds Shelf or Holds Pull List screens. When I removed an existing value from the preferred name on a patron record, the User Display Name populated with the patron's primary name. I also attempted to add spaces to the preferred name fields as a potential reason they would show as a comma, and the primary name still displayed.

But I did run into the problem on the Holds Shelf where the User Display Name does not populate with the preferred name (when it exists) but with the primary name. And the "User Alias and Display Name" only displays the alias if there is one; if there is a preferred name but not an alias, this column is blank.

[Jessica Woolford (jwoolford)]

Also noting that if a space is entered into one of the preferred name fields, it will override the display of the corresponding legal name just about everywhere. I'm unsure that is a different bug.

[Terran McCanna (tmccanna)]

Just noting for the record that the biggest complaint we've received is that when they enter a preferred first name, they expect it to *not* display the middle and last names if nothing is entered.

For instance, if Melissa Viviane Jefferson has Lizzo entered as her preferred first name and nothing entered as preferred middle and last, the expected behavior is to just display Lizzo and not Lizzo Viviane Jefferson.

Staff have sort of worked around it by adding spaces or dashes into the preferred middle and last name fields, but that's not really ideal.

[Jason Boyer (jboyer)]

Terran, I'm curious why / where a mix of preferred and regular names causes problems. Is it in the opac, notice text, staff client, or something else? I'm not sure we need to cater the use of the preferred name fields to the Cher's and Lizzo's of the world, when the better change may just be to stick to first names anywhere a patron is likely to see it and only have the full / preferred names on their preferences page and the staff client.

[Terran McCanna (tmccanna)]

The more common issue is when the patron goes by their middle name. Mary Louise Johnson who goes by Louise ends up displaying as Louise Louise Johnson.

[Galen Charlton (gmc)]

I wonder if we can can establish a convention about use of the name field(s). Specifically, that the preferred name is taken as a whole and never intermixed with the original/legal name fields. In other words, if any of the preferred name fields are set, the preferred name fields are the *only* ones that are displayed in all contexts except for any that specifically require the original/legal name. (Side note: and such contexts I expect would be quite rare outside perhaps of a legal dispute with the patron.)

One consequence of that: if the preferred names field are in use, staff should fill them out knowing that no component of the name would be "inherited" from the original/legal name fields.

A separate but related convention to consider: for all name fields, enforce by triggers that if the only thing you've in a name field is whitespace or the empty string, it gets coerced to null.

[Tiffany Little (tslittle)]

As far as display, what about just adding some verbiage? If the name displays as Johnson, Mary Louise currently, could we not just do Johnson, Mary Louise (prefers: Louise). Or just Johnson, Mary Louise (Louise)?

If a preferred name exists, display "(prefers: [first][middle][last])"? Then legal name can still be entered and visible, and preferred name doesn't need to completely replace it?

[Terran McCanna (tmccanna)]

I think that depends on where it's being used. If it's in the patron screen, something like that would work, but if it's on a hold slip or in the "Hi Louise" text on the web site or in a column, that's harder to make work smoothly.

[Terran McCanna (tmccanna)]

(My comment #8 was in response to Tiffany's comment #7)

[[e-mail] (tji)]

It is more important to me not to intermix with legal/preferred first and middle names. Last name can be "inherited".

--"A separate but related convention to consider: for all name fields, enforce by triggers that if the only thing you've in a name field is whitespace or the empty string, it gets coerced to null."

I was expecting the above behaviour.

[Rogan Hamby (rogan-hamby)]

I have some, perhaps paranoid, concerns about triggers on actor.usr checking every time a record is changed but perhaps the staff client could handle that instead, sending a null back if it is empty or just white space.

I think we also have very different scenarios at play here ranging from nicknames to more sensitive topics ranging from dead names to someone who may want anonymity for safety reasons. My instinct would be to honor the preferred name and only use it when set, not intermixing them.

[Terran McCanna (tmccanna)]

Pondering Galen's first suggestion in comment #6 - my first reaction is in favor of this idea, but I am certainly open to argument.

I am thinking of a use case like a hold shelf slip where we would typically need the last name - but that could be finessed within the print template.