Prior to bug 30063 we had a number of options in the patron dropdown that were grouped fields. I.e. choosing 'Address' would search accross multiple address fields . These have been lost, with no way for libraries to recreate them. The mappings were: standard => C4::Context->preference('DefaultPatronSearchFields') || 'surname,firstname,othernames,cardnumber,userid', email => 'email,emailpro,B_email', borrowernumber => 'borrowernumber', phone => 'phone,phonepro,B_phone,altcontactphone,mobile', address => 'streetnumber,streettype,address,address2,city,state,zipcode,country',
Created attachment 145921 [details] [review] Bug 32770: Restore patron search on all emails and phone numbers Prior to bug 30063 we had "Email" and "Phone" in the search field list that allowed a search on all email or phone attributes. This patch restores that (in an a bit ugly way, but cannot do easier). Test plan: Confirm that "Email" and "Phone" are displayed in the search field list when searching for patrons. Note that "Phone" was there already, but was only searching on the first "phone" attribute. Confirm that the search works as expected. Note for QA: I was not expecting the REST API to handle search on attributes with the DB column names, I think this is a bug.
Created attachment 145928 [details] [review] Bug 32770: Restore patron search on all emails and phone numbers Prior to bug 30063 we had "Email" and "Phone" in the search field list that allowed a search on all email or phone attributes. This patch restores that (in an a bit ugly way, but cannot do easier). Test plan: Confirm that "Email" and "Phone" are displayed in the search field list when searching for patrons. Note that "Phone" was there already, but was only searching on the first "phone" attribute. Confirm that the search works as expected. Note for QA: I was not expecting the REST API to handle search on attributes with the DB column names, I think this is a bug. Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Created attachment 145935 [details] [review] Bug 32770: [alternate] Restore patron search on all emails, phones, and addresses Prior to bug 30063 we had "Email", "Phone", and "Address" in the search field list that allowed a search on all email, phone, or address attributes. This patron restores these and makes sure the search box and the patron search filters use the same block to keep them consistent The fields are now labelled 'All emails', 'All phones', and 'Full address' to make it clear that they search multiple - including any single field in the DefaultPatronSearchFields will additionally add that to the dropdowns To test: 1 - define 'test@email.pro' as 'Secondary email' for a patron 2 - Search from 'Search patrons' address bar (visible at top of moremember.pl) 3 - Nothing is found using 'Standard' or 'Email fields' 4 - Apply patch 5 - Refresh page and repeat 6 - Nothing is found for standard, Patron is found for 'All emails' 7 - Define a unique value for patron in 'Address 2' 8 - Confirm 'Full address' search returns the patron 9 - Test with 'Secondary phone' and 'All phones' as well 10 - Repeat test from 'Patrons' module using the search on the left
The original patch did not include 'address' and did not address the search bar - I attached an alternate to cover these and make the combination of fields more clear to users
Created attachment 146331 [details] [review] Bug 32770: [alternate] Restore patron search on all emails, phones, and addresses Prior to bug 30063 we had "Email", "Phone", and "Address" in the search field list that allowed a search on all email, phone, or address attributes. This patron restores these and makes sure the search box and the patron search filters use the same block to keep them consistent The fields are now labelled 'All emails', 'All phones', and 'Full address' to make it clear that they search multiple - including any single field in the DefaultPatronSearchFields will additionally add that to the dropdowns To test: 1 - define 'test@email.pro' as 'Secondary email' for a patron 2 - Search from 'Search patrons' address bar (visible at top of moremember.pl) 3 - Nothing is found using 'Standard' or 'Email fields' 4 - Apply patch 5 - Refresh page and repeat 6 - Nothing is found for standard, Patron is found for 'All emails' 7 - Define a unique value for patron in 'Address 2' 8 - Confirm 'Full address' search returns the patron 9 - Test with 'Secondary phone' and 'All phones' as well 10 - Repeat test from 'Patrons' module using the search on the left Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Created attachment 146711 [details] [review] Bug 32770: Restore patron search on all emails, phones, and addresses Prior to bug 30063 we had "Email", "Phone", and "Address" in the search field list that allowed a search on all email, phone, or address attributes. This patron restores these and makes sure the search box and the patron search filters use the same block to keep them consistent The fields are now labelled 'All emails', 'All phones', and 'Full address' to make it clear that they search multiple - including any single field in the DefaultPatronSearchFields will additionally add that to the dropdowns To test: 1 - define 'test@email.pro' as 'Secondary email' for a patron 2 - Search from 'Search patrons' address bar (visible at top of moremember.pl) 3 - Nothing is found using 'Standard' or 'Email fields' 4 - Apply patch 5 - Refresh page and repeat 6 - Nothing is found for standard, Patron is found for 'All emails' 7 - Define a unique value for patron in 'Address 2' 8 - Confirm 'Full address' search returns the patron 9 - Test with 'Secondary phone' and 'All phones' as well 10 - Repeat test from 'Patrons' module using the search on the left Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Pushed to master for 23.05. Nice work everyone, thanks!
Created attachment 147147 [details] [review] Bug 32770: Restore phone all_phone vs all_phones That was caught by Selenium tests t/db_dependent/selenium/patrons_search.t
(In reply to Jonathan Druart from comment #8) > Created attachment 147147 [details] [review] [review] > Bug 32770: Restore phone > > all_phone vs all_phones > That was caught by Selenium tests t/db_dependent/selenium/patrons_search.t Follow-up pushed, thanks.
Many hands makes light work, thankyou everyone! Pushed to 22.11.x for the next release
Doesn't apply cleanly in 22.05.x, no backport unless it can be rebased.
Created attachment 147696 [details] [review] Bug 32770: [22.05.x] Restore patron search on all emails, phones, and addresses Prior to bug 30063 we had "Email", "Phone", and "Address" in the search field list that allowed a search on all email, phone, or address attributes. This patron restores these and makes sure the search box and the patron search filters use the same block to keep them consistent The fields are now labelled 'All emails', 'All phones', and 'Full address' to make it clear that they search multiple - including any single field in the DefaultPatronSearchFields will additionally add that to the dropdowns To test: 1 - define 'test@email.pro' as 'Secondary email' for a patron 2 - Search from 'Search patrons' address bar (visible at top of moremember.pl) 3 - Nothing is found using 'Standard' or 'Email fields' 4 - Apply patch 5 - Refresh page and repeat 6 - Nothing is found for standard, Patron is found for 'All emails' 7 - Define a unique value for patron in 'Address 2' 8 - Confirm 'Full address' search returns the patron 9 - Test with 'Secondary phone' and 'All phones' as well 10 - Repeat test from 'Patrons' module using the search on the left Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Bug 32770: Restore phone all_phone vs all_phones That was caught by Selenium tests t/db_dependent/selenium/patrons_search.t
Backported to 22.05.x for upcoming 22.05.11
depends on 30063, can't backport to 21.11
(In reply to Lucas Gass from comment #14) > Backported to 22.05.x for upcoming 22.05.11 selenium/patrons_search.t is failing, you should not ignore CI failures! It can be recreated easily, if you empty DefaultPatronSearchFields and search for patrons, you get a 500 [2023/11/29 10:14:36] [ERROR] GET /api/v1/patrons: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'me.middle_name' in 'where clause' at /usr/share/perl5/Data/Page.pm line 49>> Koha::REST::Plugin::Exceptions::__ANON__ /kohadevbox/koha/Koha/REST/Plugin/Exceptions.pm (73)
(In reply to Jonathan Druart from comment #16) > (In reply to Lucas Gass from comment #14) > > Backported to 22.05.x for upcoming 22.05.11 > > selenium/patrons_search.t is failing, you should not ignore CI failures! > > It can be recreated easily, if you empty DefaultPatronSearchFields and > search for patrons, you get a 500 > > [2023/11/29 10:14:36] [ERROR] GET /api/v1/patrons: unhandled exception > (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI > Exception: DBD::mysql::st execute failed: Unknown column 'me.middle_name' in > 'where clause' at /usr/share/perl5/Data/Page.pm line 49>> > Koha::REST::Plugin::Exceptions::__ANON__ > /kohadevbox/koha/Koha/REST/Plugin/Exceptions.pm (73) Do we open a new bug for this?
what's better for you.