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. 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> 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> Created attachment 166794 [details] [review] Bug 28633: DO NOT PUSH Schema changes (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. (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. 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> 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> Created attachment 166815 [details] [review] Bug 28633: DO NOT PUSH Schema changes Created attachment 166816 [details] [review] Bug 28633: (QA follow-up) Minor style change in dbrev Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> 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> 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. 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. (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. (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! 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? Could sort be based on effective_name? Created attachment 167163 [details] [review] Bug 28633: DO NOT PUSH - Schema changes for sort_name 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 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 (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 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. (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. 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? 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, ... ) ? 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... (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. (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 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. 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 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. This 'might' be achievable with an extension to the query_fixer stuff. Maybe time to come back to this one, and work on API improvements in a separate bug? :) 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> 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> Created attachment 173630 [details] [review] Bug 28633: DO NOT PUSH Schema changes Created attachment 173631 [details] [review] Bug 28633: (QA follow-up) Minor style change in dbrev Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> 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> 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 Created attachment 173634 [details] [review] Bug 28633: DO NOT PUSH: Schema changes 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 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> 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> Created attachment 173666 [details] [review] Bug 28633: DO NOT PUSH Schema changes Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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> 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> 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> Created attachment 173670 [details] [review] Bug 28633: DO NOT PUSH: Schema changes Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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. 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 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 Created attachment 173719 [details] [review] Bug 28633: DO NOT PUSH - Schema changes 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 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. 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 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 Created attachment 173815 [details] [review] Bug 28633: DO NOT PUSH - Schema changes Created attachment 173816 [details] [review] Bug 28633 (follow-up) Add note about disabling/hiding preferred name to sysprefs 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> 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> Created attachment 173828 [details] [review] Bug 28633: DO NOT PUSH - Schema changes Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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> 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> 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> 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> 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> Created attachment 173934 [details] [review] Bug 28633: DBIC Schema Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 173935 [details] [review] Bug 28633: (QA follow-up) Tidy Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 173936 [details] [review] Bug 28633: (QA follow-up) Fix test plans Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Some odd rebase issues, but I fixed those in QA follow-ups. All looking great here, thanks for all the work Nick. Passing QA This is going to break selenium tests, please fix ASAP. t/db_dependent/selenium/patrons_search.t 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. Pushed for 24.11! Well done everyone, thank you! Created attachment 174419 [details] [review] Bug 28633: (follow-up) Set preferred name and adjust counts for tests 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> Picked follow-up for main: Bug 28633: (follow-up) Set preferred name and adjust counts for tests 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 I don't believe those come from this - it's unrelated code, Tomas is looking I am on it. 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. Picked the last patch "Fix patrons_search.t" for main. New feature, no 24.05.x backport. 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 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. 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 :) (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. (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. Changed status back to needs documenting - this is an enhancement, and changes the interface. So changes to the manual are required, including screenshots. "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) |