Bug 28633

Summary: Add a preferred name field to patrons
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: PatronsAssignee: Nick Clemens (kidclamp) <nick>
Status: Needs documenting --- QA Contact: Martin Renvoize (ashimema) <martin.renvoize>
Severity: new feature    
Priority: P5 - low CC: andrew, clackman, david, dcook, emily.lamancusa, gmcharlt, hebah, inkeri.hakulinen+bugz, jheltibridle, jonathan.druart, kebliss, kyle.m.hall, Laura.escamilla, lisette, lucas, rcoert, smhodson123extra, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21978
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30568
GIT URL: Change sponsored?: ---
Patch complexity: Small patch Documentation contact:
Documentation submission: Text to go in the release notes:
This new feature adds a new "Preferred name" field to patron information. This is visible in staff and OPAC patron forms by default. Notes: 1. The "Preferred name" field takes precedence, and is displayed where patron names are displayed throughout Koha. 2. If the "Preferred name" field has no value, or it is hidden, the first name is displayed. 3. Notices: Use of 'firstname' in notices and other templates will continue to display the first name. Use 'preferred_name' to display the patron's preferred name. 4. Hiding fields: When hiding the preferred name field, hide it in all interfaces to avoid any discrepancies or confusion (BorrowerUnwantedField, PatronSelfModificationBorrowerUnwantedField, PatronSelfRegistrationBorrowerUnwantedField, PatronSelfModificationMandatoryField, PatronSelfRegistrationBorrowerMandatoryField). 5. Patron autocomplete: Add or remove fields to search using the DefaultPatronSearchFields system preference - if your current installation uses firstname, then this should automatically be updated to include preferred_name (and is in the default settings for new installations).
Version(s) released in:
24.11.00
Circulation function:
Bug Depends on:    
Bug Blocks: 38317, 38622, 38623, 38734, 38735    
Attachments: Bug 28633: DB Update
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: Add preferred name field to patrons
Bug 28633: Add preferred name field to patrons
Bug 28633: DB Update
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: Add preferred name field to patrons
Bug 28633: (follow-up) Show legal name and add preferredname to searches
Bug 28633: (follow-up) Show first name and add preferredname to searches
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: (follow-up) Account for bug 29695 changes
Bug 28633: (follow-up) Account for changes with bug 30063
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: (QA follow-up) Add preferred_name to ysearch
Bug 28633: (follow-up) Display effective name in JS search
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: (follow-up) Account for bug 29695 changes
Bug 28633: (follow-up) Account for changes with bug 30063
Bug 28633: (QA follow-up) Add preferred_name to ysearch
Bug 28633: (follow-up) Display effective name in JS search
Bug 28633: DO NOT PUSH Schema Changes
Bug 28633: Fix ysearch sorting
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema changes
Bug 28633: (QA follow-up) Minor style change in dbrev
Bug 28633: Make 'effective_name' embeddable
Bug 28633: DO NOT PUSH - Schema changes for sort_name
Bug 28633: POC - Add sort_name for patron
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema changes
Bug 28633: (QA follow-up) Minor style change in dbrev
Bug 28633: Make 'effective_name' embeddable
Bug 28633: POC - Add sort_name for patron
Bug 28633: DO NOT PUSH: Schema changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH Schema changes
Bug 28633: (QA follow-up) Minor style change in dbrev
Bug 28633: Make 'effective_name' embeddable
Bug 28633: POC - Add sort_name for patron
Bug 28633: DO NOT PUSH: Schema changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH - Schema changes
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH - Schema changes
Bug 28633 (follow-up) Add note about disabling/hiding preferred name to sysprefs
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH - Schema changes
Bug 28633: (follow-up) Add note about disabling/hiding preferred name to sysprefs
Bug 28633: DB update
Bug 28633: Add preferred name field to patrons
Bug 28633: DO NOT PUSH - Schema changes
Bug 28633: (follow-up) Add note about disabling/hiding preferred name to sysprefs
Bug 28633: DBIC Schema
Bug 28633: (QA follow-up) Tidy
Bug 28633: (QA follow-up) Fix test plans
Bug 28633: (follow-up) Set preferred name and adjust counts for tests
Bug 28633: (follow-up) Set preferred name and adjust counts for tests
Bug 28633: Fix patrons_search.t
Bug 28633: (follow-up) Update sample data with preferred_name

Description Nick Clemens (kidclamp) 2021-06-25 19:29:04 UTC
Some institutions store legal names in their directories and for patron imports, but would also like to be able to record 'preferred' names in the patro records.

It would be nice to have a field for preferred_name and a method to select the preferred name when it exists, and the firstname when it doesn't

Following the item we would suggest 'effective_name' - the additional method can be used in patron-title.inc and in notices to simplify name choice.
Comment 1 Lisette Scheer 2021-06-28 17:29:48 UTC
Yes, this would be lovely. We use the "Other Name" field sort of like this and train staff to use the other name. 

I'm currently working on updating our notices with TT to send the other name instead of first name if it is present but that doesn't help on the OPAC side where a patron will still see their legal name. 

Lisette
Comment 2 David Cook 2021-06-29 01:02:32 UTC
We've certainly had libraries ask for something like this, although it would also need to take into account patron searching, as I've had librarians say they want to be able to search for patrons using their preferred name rather than their legal name.
Comment 3 Nick Clemens (kidclamp) 2021-07-21 11:14:50 UTC
Created attachment 123008 [details] [review]
Bug 28633: DB Update
Comment 4 Nick Clemens (kidclamp) 2021-07-21 11:14:54 UTC
Created attachment 123009 [details] [review]
Bug 28633: DO NOT PUSH Schema Changes
Comment 5 Nick Clemens (kidclamp) 2021-07-21 11:14:57 UTC
Created attachment 123010 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferredname' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

To test:
1 - Apply patches
2 - Update database and restart all, clear browser cache
3 - Load a patron in staff module
4 - Confirm you see and can add a preferred name
5 - Confirm the preferred name now displays on patron details
6 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
    new field required or hidden
7 - Sign in as patron to opac
8 - Confirm preferred name shows
9 - Edit account on opac and confirm field is present
Comment 6 Andrew Fuerste-Henry 2021-07-22 12:27:20 UTC
With the patch applied, patron first names do not appear in the patronbriefintro sidebar on the left or in the "Checking out to [Patron name]" box on the Check out tab, even when preferred name is NULL or blank.
Comment 7 Nick Clemens (kidclamp) 2021-08-09 18:26:53 UTC
Created attachment 123658 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferredname' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

To test:
1 - Apply patches
2 - Update database and restart all, clear browser cache
3 - Load a patron in staff module
4 - Confirm you see and can add a preferred name
5 - Confirm the preferred name now displays on patron details
6 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
    new field required or hidden
7 - Sign in as patron to opac
8 - Confirm preferred name shows
9 - Edit account on opac and confirm field is present
Comment 8 Lisette Scheer 2021-08-10 15:32:52 UTC
Signed off in the Bywater Sandbox. 
I also checked and you can still search by first name. 
I do think it's a little strange that the only place to see the first name on the staff client is by editing the patron. Might be confusing if someone is trying to figure out why a patron came up in a search. 

Excited for this!

Lisette
Comment 9 Martin Renvoize (ashimema) 2021-09-30 11:06:47 UTC
I can't see that one can search on the new preferred name.. I think that's a must for this.

I also find it a little confusing on the patron page.. I think I'd actually prefer to display 'Legal name' as a distinct and clear field if we're falling through to preferred name for the main display.

We also don't appear to catch the the dropdown for 'PatronAutoComplete'.

Sorry dude.. I think this is a great start, but it need a little more work ;)
Comment 10 Nick Clemens (kidclamp) 2021-09-30 12:55:43 UTC Comment hidden (obsolete)
Comment 11 Nick Clemens (kidclamp) 2021-09-30 12:55:46 UTC Comment hidden (obsolete)
Comment 12 Nick Clemens (kidclamp) 2021-09-30 12:55:50 UTC Comment hidden (obsolete)
Comment 13 Nick Clemens (kidclamp) 2021-09-30 12:55:53 UTC Comment hidden (obsolete)
Comment 14 David Cook 2021-10-05 01:16:53 UTC
I'm not sure what I think about "Legal name" in this context. 

I suppose if there are any cases where they have something other than their legal name in first name when also using a preferred name it just becomes a data problem which can be fixed...
Comment 15 Nick Clemens (kidclamp) 2021-10-19 15:41:15 UTC
(In reply to David Cook from comment #14)
> I'm not sure what I think about "Legal name" in this context. 
> 
> I suppose if there are any cases where they have something other than their
> legal name in first name when also using a preferred name it just becomes a
> data problem which can be fixed...

"Given name"? Or should it just remain 'First name'?
Comment 16 David Cook 2021-10-20 03:52:58 UTC
(In reply to Nick Clemens from comment #15)
> (In reply to David Cook from comment #14)
> > I'm not sure what I think about "Legal name" in this context. 
> > 
> > I suppose if there are any cases where they have something other than their
> > legal name in first name when also using a preferred name it just becomes a
> > data problem which can be fixed...
> 
> "Given name"? Or should it just remain 'First name'?

Personally I think it should remain 'First name', but I'm not an expert on name terminology either heh.
Comment 17 Katrin Fischer 2021-10-20 07:21:31 UTC
A rename here would have quite a lot of consequences for documentation and such. I see a potential issue with confusing people by having a lot of different name variations and options. I think keeping the 'first name' would be good.
Comment 18 Andrew Fuerste-Henry 2021-10-20 12:05:07 UTC
(In reply to Katrin Fischer from comment #17)
> A rename here would have quite a lot of consequences for documentation and
> such. I see a potential issue with confusing people by having a lot of
> different name variations and options. I think keeping the 'first name'
> would be good.

Another +1 for "first name."
Comment 19 Nick Clemens (kidclamp) 2021-10-20 14:24:05 UTC Comment hidden (obsolete)
Comment 20 Tomás Cohen Arazi (tcohen) 2021-10-20 14:45:38 UTC
Nick,
1. You need to either exclude the attribute from the API (preferredname => undef in Koha::Patron::to_api_mapping) or add a mapping for it, and add it also to definitions/patron.json
2. I suggest you name the column preferred_name to avoid the need for any mapping :-D

Failing because it is breaking the API as-is.
Comment 21 Nick Clemens (kidclamp) 2022-01-03 15:33:34 UTC Comment hidden (obsolete)
Comment 22 Nick Clemens (kidclamp) 2022-01-03 15:33:38 UTC Comment hidden (obsolete)
Comment 23 Nick Clemens (kidclamp) 2022-01-03 15:33:42 UTC Comment hidden (obsolete)
Comment 24 Martin Renvoize (ashimema) 2022-01-31 10:35:01 UTC
Coming back to this... sorry for the hiatus. First name works fine and I agree with all the reasoning given, well argued :)

A quick test run and I'll SO.. the code all looks good to me :)
Comment 25 Martin Renvoize (ashimema) 2022-01-31 10:55:47 UTC Comment hidden (obsolete)
Comment 26 Martin Renvoize (ashimema) 2022-01-31 10:55:53 UTC Comment hidden (obsolete)
Comment 27 Martin Renvoize (ashimema) 2022-01-31 10:55:58 UTC Comment hidden (obsolete)
Comment 28 Martin Renvoize (ashimema) 2022-01-31 11:01:25 UTC
This works nicely now; To me, the name appears in the right places, looks good and isn't confusing and is searchable where one would expect it to be.

So.. signing off on that front.

It did make me take a look at some of the other name fields in patrons though, and that, I found, confusing.

'othernames' appears to partially try to do what this patch does (I'd always thought of it as 'middle names', but I note that othernames actually appears at the top of the 'contact information in double-quotes and not aligned with the rest of the information and with no label.  I also find it slightly strange that 'lastname' doesn't appear in that contact information block.

So.. in short.. I like this patch, but would like to see a little effort go into tidying up the members display data in some future bugs.. perhaps Owen could help there.?
Comment 29 Martin Renvoize (ashimema) 2022-02-18 11:15:00 UTC
See also bug 21978 where people are requesting 'middlename' get added as another field too.
Comment 30 Katrin Fischer 2022-03-27 14:17:41 UTC
I had to do a rebase for a conflict in Patrons.t and recreate the schema files locally.

Overall this works really really well already!

1) Tiny typo
+    description: patron's preferred named

2) Patron search results

In patron search results I still see the "firstname" instead of the "preferred name". 

This seems a little confusing, as this is the only place now showing the firstname. On the other hand, if someone presents an ID and I want to search forthem, I will need to make the connection. Maybe we could display the preferred name additionally to the firstname somehow?

3) Auto-complete for patrons

When I type "Cait" the entry doesn't show, only when I type "Katrin". But in the preview, it shows 'Cait' ... So there is a mismatch with what you need to type and what will show.

I am not sure how to resolve this, but maybe you have an idea or can explain reasoning?
Comment 31 Martin Renvoize (ashimema) 2022-04-20 10:20:08 UTC Comment hidden (obsolete)
Comment 32 Martin Renvoize (ashimema) 2022-04-20 10:20:13 UTC Comment hidden (obsolete)
Comment 33 Martin Renvoize (ashimema) 2022-04-20 10:20:18 UTC Comment hidden (obsolete)
Comment 34 Martin Renvoize (ashimema) 2022-04-20 10:20:23 UTC
Created attachment 133448 [details] [review]
Bug 28633: (follow-up) Account for changes with bug 30063

Bug 30063 removes the C4/Utils/DataTables/Members.pm module and instead
uses the API and a patron-search include to define the default search
fields. This follow-up adds preferred_name into the default fields in
that include now the the module has been removed
Comment 35 Martin Renvoize (ashimema) 2022-04-20 10:20:28 UTC Comment hidden (obsolete)
Comment 36 Martin Renvoize (ashimema) 2022-04-20 10:20:33 UTC Comment hidden (obsolete)
Comment 37 Martin Renvoize (ashimema) 2022-04-20 10:23:46 UTC
This is mostly a rebase taking into account bug 29695 and bug 30063.  I also added a QA follow-up to allow searching on the preferred name in the autocomplete searches.

I'm not entirely sure about the complete replacement of firstname with preferred_name everywhere.. it can lead to confusion in a few places as Katrin suggests... with the discussion on bug 21978 which lead to me opening bug 30568 I think this could play a bigger part here too.
Comment 38 Nick Clemens (kidclamp) 2022-04-20 10:38:33 UTC Comment hidden (obsolete)
Comment 39 Nick Clemens (kidclamp) 2022-04-20 10:46:06 UTC
(In reply to Katrin Fischer from comment #30)
> 1) Tiny typo
> +    description: patron's preferred named

I am not sure where you are referring to

> 2) Patron search results
> 
> In patron search results I still see the "firstname" instead of the
> "preferred name". 

Fixed

> 
> This seems a little confusing, as this is the only place now showing the
> firstname. On the other hand, if someone presents an ID and I want to search
> forthem, I will need to make the connection. Maybe we could display the
> preferred name additionally to the firstname somehow?

Preferred name is meant to be stronger than 'othernames' - it is how the patron wants to be addressed - I think in the case where there is a difference with an ID they will tell you which name to expect
 
> 3) Auto-complete for patrons
> 
> When I type "Cait" the entry doesn't show, only when I type "Katrin". But in
> the preview, it shows 'Cait' ... So there is a mismatch with what you need
> to type and what will show.

Martin fixed this

> I am not sure how to resolve this, but maybe you have an idea or can explain
> reasoning?

As above, the idea is that a preferred name is intended to the name a patron wants to be called. It is the case where the patron is not using their first name, but may still legally have that name. If a patron is using a nickname, that would be 'othernames'
Comment 40 Martin Renvoize (ashimema) 2022-04-20 11:46:53 UTC
(In reply to Nick Clemens from comment #39)
> (In reply to Katrin Fischer from comment #30)
> > 1) Tiny typo
> > +    description: patron's preferred named
> 
> I am not sure where you are referring to

I fixed it inline 'named -> name'
Comment 41 Katrin Fischer 2022-04-26 15:03:15 UTC Comment hidden (obsolete)
Comment 42 Nick Clemens (kidclamp) 2022-04-26 16:33:36 UTC Comment hidden (obsolete)
Comment 43 Nick Clemens (kidclamp) 2022-04-26 16:33:41 UTC Comment hidden (obsolete)
Comment 44 Nick Clemens (kidclamp) 2022-04-26 16:33:45 UTC Comment hidden (obsolete)
Comment 45 Nick Clemens (kidclamp) 2022-04-26 16:33:50 UTC Comment hidden (obsolete)
Comment 46 Nick Clemens (kidclamp) 2022-04-26 16:33:55 UTC Comment hidden (obsolete)
Comment 47 Nick Clemens (kidclamp) 2022-04-26 16:34:00 UTC Comment hidden (obsolete)
Comment 48 Nick Clemens (kidclamp) 2022-04-26 16:34:04 UTC Comment hidden (obsolete)
Comment 49 Nick Clemens (kidclamp) 2022-04-26 16:34:12 UTC Comment hidden (obsolete)
Comment 50 Katrin Fischer 2022-04-27 12:47:34 UTC
Sorting in the patron search results is a little off:

I have:

Katrin Fischer
Katrina Fischer
Cait Fischer (where Cait is preferred name)

I think the last should be the first entry?

Otherwise all fixes from last testing appear to be ok.
Comment 51 Katrin Fischer 2023-07-01 11:42:00 UTC
Should/can we revive this one?
Comment 52 Suzanne 2024-01-04 23:25:15 UTC
Wow! There has been a lot of work on this! We are interested in being able to have the patron record show "Preferred Name" in quotation marks in the first position followed by first and middle names and then last name. So, for example, it might show as "Sammy" Suzanne Michelle Hodson, with everything being searchable and all showing up on the patron record side bar. My idea would be to let registering patrons fill in the first and middle name field and also the preferred name field and have them show up in that order on Koha, or let libraries choose how they would like the names to show up or whether to have them hidden, if that is possible. Thanks for the great efforts on this!
Comment 53 David Cook 2024-03-13 05:01:21 UTC
(In reply to Katrin Fischer from comment #51)
> Should/can we revive this one?

I still have people asking for this, so it would be great to see it make it.
Comment 54 Nick Clemens (kidclamp) 2024-05-15 20:43:29 UTC
Created attachment 166792 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 55 Nick Clemens (kidclamp) 2024-05-15 20:43:32 UTC
Created attachment 166793 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

The 'firstname' is displayed as 'First name' on the details page, with id/class
patron_first_name to allow ajusting via JS/CSS if library wants to highlight/hide
the non-preferred name

PatronAutoComplete/ysearch is updated to use 'effective_name' method

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 56 Nick Clemens (kidclamp) 2024-05-15 20:43:35 UTC
Created attachment 166794 [details] [review]
Bug 28633: DO NOT PUSH Schema changes
Comment 57 Nick Clemens (kidclamp) 2024-05-15 20:47:26 UTC
(In reply to Katrin Fischer from comment #50)
> Sorting in the patron search results is a little off:
> 
> I have:
> 
> Katrin Fischer
> Katrina Fischer
> Cait Fischer (where Cait is preferred name)
> 
> I think the last should be the first entry?
> 
> Otherwise all fixes from last testing appear to be ok.

I still cannot fix this - patrons without a preferred_name sort before those with one - we need some sort of conditional or function to make this sort correctly afaict, and I can't seem to make that work. If someone with more datatables or API knowledge can help I'd appreciate it.
Comment 58 Katrin Fischer 2024-05-16 07:22:18 UTC
(In reply to Nick Clemens (kidclamp) from comment #57)
> (In reply to Katrin Fischer from comment #50)
> > Sorting in the patron search results is a little off:
> > 
> > I have:
> > 
> > Katrin Fischer
> > Katrina Fischer
> > Cait Fischer (where Cait is preferred name)
> > 
> > I think the last should be the first entry?
> > 
> > Otherwise all fixes from last testing appear to be ok.
> 
> I still cannot fix this - patrons without a preferred_name sort before those
> with one - we need some sort of conditional or function to make this sort
> correctly afaict, and I can't seem to make that work. If someone with more
> datatables or API knowledge can help I'd appreciate it.

Thanks for checking Nick. I think what was I was thinking is if we could create a sortable string like it works for dates and similar that matches the display format. But I have no idea how this works in detail. Before we give up on the idea, maybe we could get some more eyes on it.
Comment 59 Tomás Cohen Arazi (tcohen) 2024-05-16 11:50:06 UTC
Created attachment 166813 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 60 Tomás Cohen Arazi (tcohen) 2024-05-16 11:50:10 UTC
Created attachment 166814 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

The 'firstname' is displayed as 'First name' on the details page, with id/class
patron_first_name to allow ajusting via JS/CSS if library wants to highlight/hide
the non-preferred name

PatronAutoComplete/ysearch is updated to use 'effective_name' method

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 61 Tomás Cohen Arazi (tcohen) 2024-05-16 11:50:13 UTC
Created attachment 166815 [details] [review]
Bug 28633: DO NOT PUSH Schema changes
Comment 62 Tomás Cohen Arazi (tcohen) 2024-05-16 11:50:17 UTC
Created attachment 166816 [details] [review]
Bug 28633: (QA follow-up) Minor style change in dbrev

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 63 Tomás Cohen Arazi (tcohen) 2024-05-16 11:50:20 UTC
Created attachment 166817 [details] [review]
Bug 28633: Make 'effective_name' embeddable

This patch makes the calculated value of `Koha::Patron->effective_name`
embeddable in the patrons routes.

To test:
1. Apply this patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/patrons.t
=> SUCCESS: Tests pass!
3. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 64 Andrew Fuerste-Henry 2024-05-16 13:55:06 UTC
We should not copy preferred name when duplicating a patron, just as we do not copy over first name.

I'm very much tempted to Fail QA on this due to the search results sorting issue. When looking at a mis-sort of three patrons with the name last name it seems like a manageable speed bump, but I'm concerned about the impact on searching within a larger patron base. If any patron with a preferred name is inherently harder to find than a patron without a preferred name, then patrons with preferred names present a burden that staff may come to resent. 

I may be overthinking this.
Comment 65 Andrew Fuerste-Henry 2024-05-16 16:26:21 UTC
After soliciting some more opinions, I am marking this FQA for the search results issue. Inaccurate sorting of patrons by name will cause too much confusion for thi to be usable.
Comment 66 Katrin Fischer 2024-05-16 19:59:06 UTC
(In reply to Andrew Fuerste-Henry from comment #65)
> After soliciting some more opinions, I am marking this FQA for the search
> results issue. Inaccurate sorting of patrons by name will cause too much
> confusion for thi to be usable.

Hi Andrew, thanks for doing that - asking around. I still hope that the sorting is a solvable issue.
Comment 67 Andrew Fuerste-Henry 2024-05-16 20:05:19 UTC
(In reply to Katrin Fischer from comment #66)
> Hi Andrew, thanks for doing that - asking around. I still hope that the
> sorting is a solvable issue.

Strong agree, I'm very much in favor of this feature and would love to see it move forward!
Comment 68 Martin Renvoize (ashimema) 2024-05-17 08:41:01 UTC
I feel like this should be possible.. there's various 'IS NULL' sorting options in SQL to allow us to set whether we get NULL first or last in sort ordering.. The challenge I see is working out how to expose that via the API.. or do we just hard code somewhere a different default for null sorts?
Comment 69 Lisette Scheer 2024-05-21 16:02:37 UTC
Could sort be based on effective_name?
Comment 70 Nick Clemens (kidclamp) 2024-05-24 12:32:12 UTC
Created attachment 167163 [details] [review]
Bug 28633: DO NOT PUSH - Schema changes for sort_name
Comment 71 Nick Clemens (kidclamp) 2024-05-24 12:32:15 UTC
Created attachment 167164 [details] [review]
Bug 28633: POC - Add sort_name for patron

This is just a possible solution, add a new "sort" name for patrons - we could expand the calculations
here if needed, but essentially we just store the effective name, making it available for SQL sorting
Comment 72 Andrew Fuerste-Henry 2024-05-24 14:57:39 UTC
Sorting almost works correctly with these patches. The following three patrons show up in this order in a default patron search (ascending name sort):
 - surname: Acevedo, preferred_name: [blank], firstname: Hank
 - surname: Acevedo, preferred_name: [blank], firstname: Henry
 - surname: Acevedo, preferred_name: [blank], firstname: Hosea

When I added a preferred_name I got:
 - surname: Acevedo, preferred_name: Angel, firstname: Henry
 - surname: Acevedo, preferred_name: [blank], firstname: Hank
 - surname: Acevedo, preferred_name: [blank], firstname: Hosea

And then with a second preferred_name:
 - surname: Acevedo, preferred_name: Angel, firstname: Henry
 - surname: Acevedo, preferred_name: [blank], firstname: Hosea
 - surname: Acevedo, preferred_name: Zeus, firstname: Hank

BUT things go weird if preferred_name is NULL -- in KTD the default data has preferred_name null but saves new/edited patrons with a blank instead. In the real world, I imagine patrons could be imported with a NULL value. With NULL preferred_names I get:

 - surname: Acevedo, preferred_name: NULL, firstname: Henry
 - surname: Acevedo, preferred_name: NULL, firstname: Hosea
 - surname: Acevedo, preferred_name: NULL, firstname: Hank
Comment 73 Nick Clemens (kidclamp) 2024-05-30 11:45:02 UTC
(In reply to Andrew Fuerste-Henry from comment #72)
> BUT things go weird if preferred_name is NULL -- in KTD the default data has
> preferred_name null but saves new/edited patrons with a blank instead. In
> the real world, I imagine patrons could be imported with a NULL value. With
> NULL preferred_names I get:
> 
>  - surname: Acevedo, preferred_name: NULL, firstname: Henry
>  - surname: Acevedo, preferred_name: NULL, firstname: Hosea
>  - surname: Acevedo, preferred_name: NULL, firstname: Hank

I originally thought we could simply add a default value - however, TEXT columns cannot have a default value in MySQL - MariaDB does allow this

Either we need to supply the default on storing - or build and internal functions - OR make sort_name a VARCHAR, but it would be storing a longtext so would be problematic - I am not sure why name fields are longtext

This may mean sort_name is a unacceptable solution
Comment 74 Emily Lamancusa (emlam) 2024-06-26 17:52:33 UTC
Andrew, how are you setting the preferred_names to NULL in your last example? I'm wondering if it's the NULLs per se that are causing the issue, or if the problem is that sort_name isn't getting updated.
Comment 75 Andrew Fuerste-Henry 2024-07-01 17:25:57 UTC
(In reply to Emily Lamancusa from comment #74)
> Andrew, how are you setting the preferred_names to NULL in your last
> example? I'm wondering if it's the NULLs per se that are causing the issue,
> or if the problem is that sort_name isn't getting updated.

I don't believe there is a way to use the GUI to either create a patron with a NULL preferred name or edit a patron to have one. I believe patron imports are the only way to get a NULL.
Comment 76 Martin Renvoize (ashimema) 2024-07-02 12:35:34 UTC
I think only patron imports directly into the DB and not via any of the Koha tools is the only way this can happen.

Personally.. I actually think this is OK for now.. perhaps a scripts to 'fix sort_name' inconsistencies down the line or even a little warning in the about page.

But personally I don't think we should hold this bug back any longer?
Comment 77 Katrin Fischer 2024-07-02 12:40:37 UTC
Bear with me if this has been asked before, but do we really need the additional database column? Could we not create it somehow "virtually". I was thinking of something like in SQL:

SELECT COALESCE (preferredname, ... ) ?
Comment 78 Martin Renvoize (ashimema) 2024-07-02 12:53:19 UTC
Something like `ORDER BY COALESCE(NULLIF(preferred_name, ''), first_name), last_name` you mean?

We'll still need to work out how to wrap that for the API...
Comment 79 Katrin Fischer 2024-07-02 13:00:51 UTC
(In reply to Martin Renvoize from comment #78)
> Something like `ORDER BY COALESCE(NULLIF(preferred_name, ''), first_name),
> last_name` you mean?
> 
> We'll still need to work out how to wrap that for the API...

Yes, because I think having it as a real database column might add some technical debt/more stuff to maintain. If we could avoid it with reasonable effort that might be nice.
Comment 80 Nick Clemens (kidclamp) 2024-07-02 13:03:48 UTC
(In reply to Katrin Fischer from comment #79)
> (In reply to Martin Renvoize from comment #78)
> > Something like `ORDER BY COALESCE(NULLIF(preferred_name, ''), first_name),
> > last_name` you mean?
> > 
> > We'll still need to work out how to wrap that for the API...
> 
> Yes, because I think having it as a real database column might add some
> technical debt/more stuff to maintain. If we could avoid it with reasonable
> effort that might be nice.

It's the combination of API and Datatables here that I was unable to resolve - the query is being bult by datatables, so I think we would need to intercept the sorting column in the API and convert it to the SQL we need.

IMO the column simplifies the code we need in the end, but am happy to see if someone else can solve the API issue
Comment 81 Katrin Fischer 2024-07-02 13:06:44 UTC
As a new feature we have a little bit more time for this one. Let's try and think it over one more time to see if we have missed something that could make things a little easier.
Comment 82 Martin Renvoize (ashimema) 2024-07-02 13:08:53 UTC
It has been coded and working through issues wince 2021... we can't sit at 'perfect it more' forever ;P

That said.. I'll take a look and see if there's a way we can overload at the dbic level for sorting
Comment 83 Katrin Fischer 2024-07-02 13:10:15 UTC
I didn't mean weeks - just a few days, maybe to the end of the week? See if we can find some more brains to pick for an idea.
Comment 84 Martin Renvoize (ashimema) 2024-07-02 13:32:06 UTC
This 'might' be achievable with an extension to the query_fixer stuff.
Comment 85 Emily Lamancusa (emlam) 2024-08-15 17:45:20 UTC
Maybe time to come back to this one, and work on API improvements in a separate bug? :)
Comment 86 Nick Clemens (kidclamp) 2024-10-29 12:27:30 UTC
Created attachment 173628 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 87 Nick Clemens (kidclamp) 2024-10-29 12:27:33 UTC
Created attachment 173629 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

The 'firstname' is displayed as 'First name' on the details page, with id/class
patron_first_name to allow ajusting via JS/CSS if library wants to highlight/hide
the non-preferred name

PatronAutoComplete/ysearch is updated to use 'effective_name' method

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 88 Nick Clemens (kidclamp) 2024-10-29 12:27:36 UTC
Created attachment 173630 [details] [review]
Bug 28633: DO NOT PUSH Schema changes
Comment 89 Nick Clemens (kidclamp) 2024-10-29 12:27:39 UTC
Created attachment 173631 [details] [review]
Bug 28633: (QA follow-up) Minor style change in dbrev

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 90 Nick Clemens (kidclamp) 2024-10-29 12:27:42 UTC
Created attachment 173632 [details] [review]
Bug 28633: Make 'effective_name' embeddable

This patch makes the calculated value of `Koha::Patron->effective_name`
embeddable in the patrons routes.

To test:
1. Apply this patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/patrons.t
=> SUCCESS: Tests pass!
3. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 91 Nick Clemens (kidclamp) 2024-10-29 12:27:45 UTC
Created attachment 173633 [details] [review]
Bug 28633: POC - Add sort_name for patron

This is just a possible solution, add a new "sort" name for patrons - we could expand the calculations
here if needed, but essentially we just store the effective name, making it available for SQL sorting
Comment 92 Nick Clemens (kidclamp) 2024-10-29 12:27:48 UTC
Created attachment 173634 [details] [review]
Bug 28633: DO NOT PUSH: Schema changes
Comment 93 Nick Clemens (kidclamp) 2024-10-29 12:28:33 UTC
Rebased, I am happy to have anyone else try to work on query fixer, but I think this works in the large sense and can be improved in the future
Comment 94 Emily Lamancusa (emlam) 2024-10-29 15:45:42 UTC
Created attachment 173664 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 95 Emily Lamancusa (emlam) 2024-10-29 15:45:45 UTC
Created attachment 173665 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

Additionally it adds a method 'effective_name' to choose the preferred name if present
and fall back to firstname

The 'firstname' is displayed as 'First name' on the details page, with id/class
patron_first_name to allow ajusting via JS/CSS if library wants to highlight/hide
the non-preferred name

PatronAutoComplete/ysearch is updated to use 'effective_name' method

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 96 Emily Lamancusa (emlam) 2024-10-29 15:45:48 UTC
Created attachment 173666 [details] [review]
Bug 28633: DO NOT PUSH Schema changes

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 97 Emily Lamancusa (emlam) 2024-10-29 15:45:51 UTC
Created attachment 173667 [details] [review]
Bug 28633: (QA follow-up) Minor style change in dbrev

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 98 Emily Lamancusa (emlam) 2024-10-29 15:45:54 UTC
Created attachment 173668 [details] [review]
Bug 28633: Make 'effective_name' embeddable

This patch makes the calculated value of `Koha::Patron->effective_name`
embeddable in the patrons routes.

To test:
1. Apply this patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/patrons.t
=> SUCCESS: Tests pass!
3. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 99 Emily Lamancusa (emlam) 2024-10-29 15:45:56 UTC
Created attachment 173669 [details] [review]
Bug 28633: POC - Add sort_name for patron

This is just a possible solution, add a new "sort" name for patrons - we could expand the calculations
here if needed, but essentially we just store the effective name, making it available for SQL sorting

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 100 Emily Lamancusa (emlam) 2024-10-29 15:45:59 UTC
Created attachment 173670 [details] [review]
Bug 28633: DO NOT PUSH: Schema changes

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 101 Emily Lamancusa (emlam) 2024-10-29 15:47:26 UTC
Testing notes:
2 - Update database and restart all, clear browser cache
Also need to do a yarn build before restarting; otherwise attempting any patron search will throw an ajax error that preferred_name and sort_name are not allowed.

Auto-complete should also use sort_name - it still seems to be sorting by firstname. (Not a blocker)

Duplicating a patron shouldn't carry over the original patron's preferred name, but currently it does. (Not a blocker)

I also tested searching and patron imports since those were a sticking point previously, using the same data from #c72 (including importing patrons with no preferred name using Koha's import patron tool), and all the sorts worked correctly.
Comment 102 Nick Clemens (kidclamp) 2024-10-30 13:16:48 UTC
Created attachment 173717 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def
and sets preferred name to firstname
Comment 103 Nick Clemens (kidclamp) 2024-10-30 13:16:51 UTC
Created attachment 173718 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden

With this patchset preferred_name will always be set - either to the firstname, or a specified value.

PatronAutoComplete/ysearch is updated to use 'preferred_name'

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed
Comment 104 Nick Clemens (kidclamp) 2024-10-30 13:16:54 UTC
Created attachment 173719 [details] [review]
Bug 28633: DO NOT PUSH - Schema changes
Comment 105 Nick Clemens (kidclamp) 2024-10-30 13:19:36 UTC
New patches based on feedback from Martin - removed effective_name and sort_name in favor of setting preferred_name from firstname if not defined

When the field is hidden, it should be largely invisible to users, except in action log changes

When visible - it will always be set, so may be duplicated for patrons with no preferred name, but I think it is better to be obvious than to hide what is happening. Patron displays will always use preferred_name, only on patron details/etc would you see both
Comment 106 Emily Lamancusa (emlam) 2024-10-30 17:18:02 UTC
Testing notes: after applying patch and running updatedatabase, also need to run yarn build, then restart_all

The test plan works and sorting works as expected, both in auto-complete and in the results table, including with patrons that were added using Koha's patron import tool.

However, there is one blocker for me with this version - I think the way the feature is functionally enabled/disabled based on the collective settings of all 3 of the Unwanted prefs is going to be very confusing to users. It is especially an issue that adding preferred_name to all 3 Unwanted prefs will cause existing preferred_name data to be overwritten piecemeal, as patrons happen to get edited for any reason, without warning that this will happen.

At the very least, there needs to be a clear warning in the description of each of the Unwanted prefs stating that if preferred_name is marked unwanted in all 3, that existing preferred_name data will be overwritten as patrons are edited. Personally, I think the best solution would be for the first name to overwrite the preferred_name if and only if (preferred_name eq firstname or preferred_name is empty), regardless of how the Unwanted prefs are set. As far as I know, all other fields retain their data unless explicitly deleted, even if they're fully hidden, so I think that behavior would be fine in this case, too.
Comment 107 Nick Clemens (kidclamp) 2024-10-31 16:21:46 UTC
Created attachment 173813 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def
and sets preferred name to firstname
Comment 108 Nick Clemens (kidclamp) 2024-10-31 16:21:49 UTC
Created attachment 173814 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden

With this patchset preferred_name will always be set - either to the firstname, or a specified value.

PatronAutoComplete/ysearch is updated to use 'preferred_name'

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed
Comment 109 Nick Clemens (kidclamp) 2024-10-31 16:21:52 UTC
Created attachment 173815 [details] [review]
Bug 28633: DO NOT PUSH - Schema changes
Comment 110 Nick Clemens (kidclamp) 2024-10-31 16:21:55 UTC
Created attachment 173816 [details] [review]
Bug 28633 (follow-up) Add note about disabling/hiding preferred name to sysprefs
Comment 111 Emily Lamancusa (emlam) 2024-10-31 17:27:25 UTC
Created attachment 173826 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def
and sets preferred name to firstname

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 112 Emily Lamancusa (emlam) 2024-10-31 17:27:28 UTC
Created attachment 173827 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden

With this patchset preferred_name will always be set - either to the firstname, or a specified value.

PatronAutoComplete/ysearch is updated to use 'preferred_name'

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 113 Emily Lamancusa (emlam) 2024-10-31 17:27:31 UTC
Created attachment 173828 [details] [review]
Bug 28633: DO NOT PUSH - Schema changes

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 114 Emily Lamancusa (emlam) 2024-10-31 17:27:34 UTC
Created attachment 173829 [details] [review]
Bug 28633: (follow-up) Add note about disabling/hiding preferred name to sysprefs

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 115 Martin Renvoize (ashimema) 2024-11-04 15:44:29 UTC
Created attachment 173930 [details] [review]
Bug 28633: DB update

This adds the field to necessary tables and updates API and columns def
and sets preferred name to firstname

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 116 Martin Renvoize (ashimema) 2024-11-04 15:44:33 UTC
Created attachment 173931 [details] [review]
Bug 28633: Add preferred name field to patrons

This patch adds a new field 'preferred_name' to the patron record.

On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden

With this patchset preferred_name will always be set - either to the firstname, or a specified value.

PatronAutoComplete/ysearch is updated to use 'preferred_name'

To test:
 1 - Apply patches
 2 - Update database and restart all, clear browser cache
 3 - Load a patron in staff module
 4 - Confirm you see and can add a preferred name
 5 - Confirm the preferred name and first name now displays on patron details
 6 - Remove first name from patron record and confirm it no longer shows
 7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
     new field required or hidden
 8 - Sign in as patron to opac
 9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 117 Martin Renvoize (ashimema) 2024-11-04 15:44:37 UTC
Created attachment 173932 [details] [review]
Bug 28633: DO NOT PUSH - Schema changes

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 118 Martin Renvoize (ashimema) 2024-11-04 15:44:40 UTC
Created attachment 173933 [details] [review]
Bug 28633: (follow-up) Add note about disabling/hiding preferred name to sysprefs

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 119 Martin Renvoize (ashimema) 2024-11-04 15:44:44 UTC
Created attachment 173934 [details] [review]
Bug 28633: DBIC Schema

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 120 Martin Renvoize (ashimema) 2024-11-04 15:44:48 UTC
Created attachment 173935 [details] [review]
Bug 28633: (QA follow-up) Tidy

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 121 Martin Renvoize (ashimema) 2024-11-04 15:44:52 UTC
Created attachment 173936 [details] [review]
Bug 28633: (QA follow-up) Fix test plans

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 122 Martin Renvoize (ashimema) 2024-11-04 15:45:34 UTC
Some odd rebase issues, but I fixed those in QA follow-ups.

All looking great here, thanks for all the work Nick.

Passing QA
Comment 123 Katrin Fischer 2024-11-11 13:11:40 UTC
This is going to break selenium tests, please fix ASAP.

t/db_dependent/selenium/patrons_search.t
Comment 124 Katrin Fischer 2024-11-11 13:14:52 UTC
Hm, I am going to push this anyway, but:

1) Tests need to be fixed. (blocker)
2) I would prefer a follow-up that hid this field for updating installations. As we show in the OPAC this would make it less disruptive.
Comment 125 Katrin Fischer 2024-11-11 13:15:23 UTC
Pushed for 24.11!

Well done everyone, thank you!
Comment 126 Nick Clemens (kidclamp) 2024-11-12 14:49:41 UTC
Created attachment 174419 [details] [review]
Bug 28633: (follow-up) Set preferred name and adjust counts for tests
Comment 127 Tomás Cohen Arazi (tcohen) 2024-11-12 15:11:13 UTC
Created attachment 174420 [details] [review]
Bug 28633: (follow-up) Set preferred name and adjust counts for tests

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 128 Katrin Fischer 2024-11-12 15:55:53 UTC
Picked follow-up for main:
Bug 28633: (follow-up) Set preferred name and adjust counts for tests
Comment 129 Katrin Fischer 2024-11-12 15:57:35 UTC
Hm, with the patch applied the test doesn't pass yet. 

I have:

Running tests (1)
	* Proving /kohadevbox/koha/t/db_dependent/selenium/patrons_search.t KO!

STRACE:	/usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...} 
	/usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
	(eval 2045):1 in Selenium::Remote::Driver::__ANON__
	(eval 2047):2 in Selenium::Remote::Driver::__ANON__
	(eval 2019):17 in Selenium::Remote::Driver::_execute_command
	/usr/share/perl5/Selenium/Remote/WebElement.pm:260 in Selenium::Remote::WebElement::_execute_command
	/kohadevbox/koha/t/db_dependent/selenium/patrons_search.t:430 in Selenium::Remote::WebElement::clear
	/usr/share/perl/5.36/Test/Builder.pm:374 in main::__ANON__
	/usr/share/perl/5.36/Test/Builder.pm:374 in (eval)
	/usr/share/perl/5.36/Test/More.pm:809 in Test::Builder::subtest
	/kohadevbox/koha/t/db_dependent/selenium/patrons_search.t:463 in Test::More::subtest
	/usr/share/perl/5.36/Test/Builder.pm:374 in main::__ANON__
	/usr/share/perl/5.36/Test/Builder.pm:374 in (eval)
	/usr/share/perl/5.36/Test/More.pm:809 in Test::Builder::subtest
	/kohadevbox/koha/t/db_dependent/selenium/patrons_search.t:467 in Test::More::subtest

         # Looks like you planned 7 tests but ran 1.
 
    #   Failed test 'filter by date of birth'
    #   at /kohadevbox/koha/t/db_dependent/selenium/patrons_search.t line 463.
     # Looks like you failed 1 test of 28.
 
#   Failed test 'Search patrons'
#   at /kohadevbox/koha/t/db_dependent/selenium/patrons_search.t line 467.
Error while executing command: stale element reference: The element reference of <input type="text"> is stale; either the element is no longer attached to the DOM, it is not in the current frame context, or the document has been refreshed at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
 at /usr/share/perl5/Selenium/Remote/Driver.pm line 356.
 # Looks like your test exited with 11 just after 1.
 /kohadevbox/koha/t/db_dependent/selenium/patrons_search.t .. 
Dubious, test returned 11 (wstat 2816, 0xb00)
Failed 2/2 subtests
Comment 130 Nick Clemens (kidclamp) 2024-11-13 13:46:26 UTC
I don't believe those come from this - it's unrelated code, Tomas is looking
Comment 131 Jonathan Druart 2024-11-13 14:22:18 UTC
I am on it.
Comment 132 Jonathan Druart 2024-11-13 14:49:43 UTC
Created attachment 174472 [details] [review]
Bug 28633: Fix patrons_search.t

This does not belong here, but raised to me here, so attaching on this
one.
This feels like it's coming from bug 33484, but those tests were passing
after it has been pushed.

This patch fixes the following error:
Error while executing command: stale element reference: The element reference of <input type="text"> is stale; either the element is no longer attached to the DOM, it is not in the current frame context, or the document has been refreshed at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.

Since bug 33484 the row with the filters is redrawn on table redraw. So
we need to search for the input every time the table is redrawn.
Comment 133 Katrin Fischer 2024-11-13 15:41:20 UTC
Picked the last patch "Fix patrons_search.t" for main.
Comment 134 Lucas Gass (lukeg) 2024-11-22 21:46:38 UTC
New feature, no 24.05.x backport.
Comment 135 David Nind 2024-11-26 00:16:24 UTC
See the chat discussion about the sample data used by KTD - it is currently only displaying the surname in patron search results, patron page, and wherever the patron name is displayed in Koha. 

Chat discussion: https://chat.koha-community.org/koha-community/pl/xqhc3c8g7tdu38fyp971z4oiqa

I'm also unsure about patron autocomplete and DefaultPatronSearchFields in KTD, as it doesn't include preferred_name by default when it is started up. 

The assumption is that the database update will take care of things for existing installations, unless I have misunderstood:
- Preferred name field added to patron information
- Patron autocomplete: preferred_name added to DefaultPatronSearchFields
Comment 136 Martin Renvoize (ashimema) 2024-12-04 13:23:19 UTC
Created attachment 175177 [details] [review]
Bug 28633: (follow-up) Update sample data with preferred_name

This patch updates the sample_date, as used in koha-testing-docker, with
the new preferred_name field.
Comment 137 Katrin Fischer 2024-12-04 14:44:31 UTC
Could you move the patch to a separate bug please? Only reason: that way I don't need to remember to remove this "new feature" form release notes for 25.05 manually in 6 months :)
Comment 138 Katrin Fischer 2024-12-04 14:44:48 UTC
(In reply to Katrin Fischer from comment #137)
> Could you move the patch to a separate bug please? Only reason: that way I
> don't need to remember to remove this "new feature" form release notes for
> 25.05 manually in 6 months :)

... or I will do it in a few mins.
Comment 139 Katrin Fischer 2024-12-04 15:17:43 UTC
(In reply to Katrin Fischer from comment #138)
> (In reply to Katrin Fischer from comment #137)
> > Could you move the patch to a separate bug please? Only reason: that way I
> > don't need to remember to remove this "new feature" form release notes for
> > 25.05 manually in 6 months :)
> 
> ... or I will do it in a few mins.

Moved to bug 38622.
Comment 140 David Nind 2024-12-18 20:21:10 UTC
Changed status back to needs documenting - this is an enhancement, and changes the interface. So changes to the manual are required, including screenshots.
Comment 141 Jonathan Druart 2025-01-23 10:35:59 UTC
"First name" is displayed on the patron detail page, but it's confusing, see https://chat.koha-community.org/koha-community/pl/6rza7668wby6mpodr8anhr9tre

A solution would be to display it only if different than the preferred name (there is a diff suggested in the thread)