Description
Nick Clemens (kidclamp)
2021-06-25 19:29:04 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 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. Created attachment 123008 [details] [review] Bug 28633: DB Update Created attachment 123009 [details] [review] Bug 28633: DO NOT PUSH Schema Changes 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 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. 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 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 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 ;) Created attachment 125497 [details] [review] Bug 28633: DB Update Created attachment 125498 [details] [review] Bug 28633: DO NOT PUSH Schema Changes Created attachment 125499 [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 Created attachment 125500 [details] [review] Bug 28633: (follow-up) Show legal name and add preferredname to searches This patch adds to the DB update a condition to add 'preferredname' to DefaultPatronSearchFields. It also adjust the koha defaults to include it if the pref is empty The 'firstname' is displayed as 'Legal name' on the details page, with id/class to allow ajusting via JS/CSS PatronAutoComplete/ysearch is updated to use 'effective_name' method To test: 1 - Aply patches and updatedatabase and restart_all 2 - Add a preferredname to a patron 3 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname Add preferredname if not 4 - Perform checkout and patron search using preferredname, confirm patron is found 5 - On patron's detail page confirm 'Legal name' shows 6 - Remove patron's first name, confirm 'Legal name' is no longer present 7 - Enable PatronAutoComplete system preference 8 - Type patron's surname into Checkout or patron search but don't hit enter 9 - Confirm patron is dsiplayed with 'preferredname' in the preview 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... (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'? (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. 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. (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." Created attachment 126591 [details] [review] Bug 28633: (follow-up) Show first name and add preferredname to searches This patch adds to the DB update a condition to add 'preferredname' to DefaultPatronSearchFields. It also adjust the koha defaults to include it if the pref is empty 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 and updatedatabase and restart_all 2 - Add a preferredname to a patron 3 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname Add preferredname if not 4 - Perform checkout and patron search using preferredname, confirm patron is found 5 - On patron's detail page confirm 'First name' shows 6 - Remove patron's first name, confirm 'First name' is no longer present 7 - Enable PatronAutoComplete system preference 8 - Type patron's surname into Checkout or patron search but don't hit enter 9 - Confirm patron is dsiplayed with 'preferredname' in the preview 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. Created attachment 128968 [details] [review] Bug 28633: DB update This adds the field to necessary tables and updates API and columns def Created attachment 128969 [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 Created attachment 128970 [details] [review] Bug 28633: DO NOT PUSH Schema Changes 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 :) Created attachment 130000 [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> Created attachment 130001 [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> Created attachment 130002 [details] [review] Bug 28633: DO NOT PUSH Schema Changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> 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.? See also bug 21978 where people are requesting 'middlename' get added as another field too. 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? Created attachment 133445 [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> Created attachment 133446 [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> Created attachment 133447 [details] [review] Bug 28633: (follow-up) Account for bug 29695 changes During rebase of this patchset we drop the columns.def and borrowers.json changes introduced. We store this mapping in the module now, so this patch does that. 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 Created attachment 133449 [details] [review] Bug 28633: DO NOT PUSH Schema Changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 133450 [details] [review] Bug 28633: (QA follow-up) Add preferred_name to ysearch This adds preferred_name to the search fields in the autocomplete search system. 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. Created attachment 133451 [details] [review] Bug 28633: (follow-up) Display effective name in JS search Also I fix the other header search, and ensure the 'Standard' option wil appear in dropdowns (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' (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' Can you please rebase? Careful with the first conflict - h3 changed to h1 in master and the section was moved a little downwards. Created attachment 133958 [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> Created attachment 133959 [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> Created attachment 133960 [details] [review] Bug 28633: (follow-up) Account for bug 29695 changes During rebase of this patchset we drop the columns.def and borrowers.json changes introduced. We store this mapping in the module now, so this patch does that. Created attachment 133961 [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 Created attachment 133962 [details] [review] Bug 28633: (QA follow-up) Add preferred_name to ysearch This adds preferred_name to the search fields in the autocomplete search system. Created attachment 133963 [details] [review] Bug 28633: (follow-up) Display effective name in JS search Also I fix the other header search, and ensure the 'Standard' option wil appear in dropdowns Created attachment 133964 [details] [review] Bug 28633: DO NOT PUSH Schema Changes Created attachment 133965 [details] [review] Bug 28633: Fix ysearch sorting This adds an IF conditional to the sorting to sort by preferred name or firstname I add the colmns to data for main patron searhc, but I cannot solve sorting there 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. Should/can we revive this one? 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! (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. |