After getting a range of results from a patron search on the members/members-home.pl if you use the patron filtering a new search is performed rather than the existing results of the first search being filtered down. This makes finding a user in a institution with a large number of similarly named patrons very difficult.
Created attachment 72496 [details] [review] Bug 20346 - Server side patron filtering implemented Server side (in the svc/members/search file) perl logic for filtering results returned from patron searches checks all patron data fields for a match with the filter value. This filtering works in the following steps: when filtering is initiated the original search using the original search query is run again and then the filter value is used to filter the resulting data, thereby using both the search and filter values to easily find a patron. The submitted filter value is automatically checked against every patron value in every patron record returned from the search and so there is no need for a specific data value to be selected with the select dropdown box id=searchfieldstype_filter and so that select dropdown has been removed due to this redundancy. This filter works for both filtering based on finding a match containing the filter value and, filtering based on finding a match starting with the filter value. Test plan: 1. Go to /members/members-home.pl and create 4 users. Make them all have the same first and last name but vary the homebranch, email addresses and dates of birth 2. Perform a search by writing in the first and last name combination shared by the 4 users and you should get 4 results 3. Filter by writing in the email adrr Sponsored-By: Catalyst IT
Created attachment 72520 [details] New patron filter with the search field type dropdown box removed
Created attachment 72523 [details] [review] Bug 20346 - Server side patron filtering implemented Server side (in the svc/members/search file) perl logic for filtering results returned from patron searches checks all patron data fields for a match with the filter value. This filtering works in the following steps: when filtering is initiated the original search using the original search query is run again and then the filter value is used to filter the resulting data, thereby using both the search and filter values to easily find a patron. The submitted filter value is automatically checked against every patron value in every patron record returned from the search and so there is no need for a specific data value to be selected with the select dropdown box id=searchfieldstype_filter and so that select dropdown has been removed due to this redundancy. This filter works for both filtering based on finding a match containing the filter value and, filtering based on finding a match starting with the filter value. A tooltip is displayed on the searchmember_filter input box to inform the user what format they should enter date formats. The tooltip tells the user to follow the date format of the dateformat syspref, meaning if the Koha instance has the 'metric' dataformat syspref value set then the tooltip will tell the user to enter a date value in the format dd/mm/yyyy Test plan: 1. Go to /members/members-home.pl and create 4 users. Make 3 of them have the same first and last name (e.g. first name = 'Fred' and last name ='Jones') but vary the homebranch, email addresses (e.g. fred@gmail.com, fred@hotmail.com, fredj@gmail.com (make this user have a date of birth of 1st jan 1980)) and make the fourth user have the first and last name of "Fred" "Smith" 2. Perform a search by writing in the 'Jones' value and you should get 3 results 3. Filter by writing in the word "Fred", with the search field ="standard" and searchtype="Contains" and this will give you 4 results because a new search for all users containing "Fred" is performed rather than filtering the results of the "Jones" search for the term "Fred" 4. Apply patch 5. Restart plack, apache2 and memcached 6. Refresh the patron page 7. Notice the search field dropdown has been removed because the filtering now automatically checks all patron data fields. Also notice when you hover over the filter textbox a tooltip message is displayed informing you the appropriate format for you to input date values in. This date format recommended is based on the value of the dateformat syspref 8. Repeat step 2 and you should get 3 results 9. Repeat step 3 and notice you get 3 results because the filtering is happening on the results of search rather than performing a new search 10. Perform another filter of the search by inputting the date 1st jan 1980 in the appropriate format described in the tooltip and the patron page for the patron with the email address fredj@gmail.com should be displayed Sponsored-By: Catalyst IT
Created attachment 72623 [details] [review] Bug 20346 - Server side patron filtering implemented - Amended Server side (in the svc/members/search file) perl logic for filtering results returned from patron searches checks all patron data fields for a match with the filter value. This filtering works in the following steps: when filtering is initiated the original search using the original search query is run again and then the filter value is used to filter the resulting data, thereby using both the search and filter values to easily find a patron. The submitted filter value is automatically checked against every patron value in every patron record returned from the search and so there is no need for a specific data value to be selected with the select dropdown box id=searchfieldstype_filter and so that select dropdown has been removed due to this redundancy. This filter works for both filtering based on finding a match containing the filter value and, filtering based on finding a match starting with the filter value. A tooltip is displayed on the searchmember_filter input box to inform the user what format they should enter date formats. The tooltip tells the user to follow the date format of the dateformat syspref, meaning if the Koha instance has the 'metric' dataformat syspref value set then the tooltip will tell the user to enter a date value in the format dd/mm/yyyy Test plan: 1. Go to /members/members-home.pl and create 4 users. Make 3 of them have the same first and last name (e.g. first name = 'Fred' and last name ='Jones') but vary the homebranch, email addresses (e.g. fred@gmail.com, fred@hotmail.com, fredj@gmail.com (make this user have a date of birth of 1st jan 1980)) and make the fourth user have the first and last name of "Fred" "Smith" 2. Perform a search by writing in the 'Jones' value and you should get 3 results 3. Filter by writing in the word "Fred", with the search field ="standard" and searchtype="Contains" and this will give you 4 results because a new search for all users containing "Fred" is performed rather than filtering the results of the "Jones" search for the term "Fred" 4. Apply patch 5. Restart plack, apache2 and memcached 6. Refresh the patron page 7. Notice the search field dropdown has been removed because the filtering now automatically checks all patron data fields. Also notice when you hover over the filter textbox a tooltip message is displayed informing you the appropriate format for you to input date values in. This date format recommended is based on the value of the dateformat syspref 8. Repeat step 2 and you should get 3 results 9. Repeat step 3 and notice you get 3 results because the filtering is happening on the results of search rather than performing a new search 10. Perform another filter of the search by inputting the date 1st jan 1980 in the appropriate format described in the tooltip and the patron page for the patron with the email address fredj@gmail.com should be displayed Sponsored-By: Catalyst IT
Created attachment 72624 [details] [review] Bug 20346 - Amended Server side patron filtering The number of results returned has been fixed so it is not affected by what the user sets for the number of records they want displayed on each page. In addition to ensuring all matching patrons are returned no matter what the numberof patrons to be displayed on each page is, filtering also takes place over all returned patrons and not just those displayed on the current page this ensures filtering finds all matching patrons. Test plan: The same as the previous bug 20346 patch Sponsored-By: Catalyst IT
Created attachment 72815 [details] [review] Bug 20346 - New wording above the patron table on the patron page Now the wording of the text above the patron result table is in the format 'Users found for: <searchtype> <term> filtered by <filtersearchtype> <filterterm>' Test plan: Same as the two previous patches for this bug, however notice after applying this patch and perform a search and filter event that the wording of this text above the patron result table is changed to the format 'Users found for: <searchtype> <term> filtered by <filtersearchtype> <filterterm>' Sponsored-By: Catalyst IT
Comment on attachment 72523 [details] [review] Bug 20346 - Server side patron filtering implemented Untranslatable strings: + $('#searchmember_filter').attr("title","Please enter date inputs in the format mm/dd/yyyy").tooltip('show'); + $('#searchmember_filter').attr("title","Please enter date inputs in the format dd/mm/yyyy").tooltip('show'); + $('#searchmember_filter').attr("title","Please enter date inputs in the format yyyy-mm-dd").tooltip('show'); + $('#searchmember_filter').attr("title","Please enter date inputs in the format dd.mm.yyyy").tooltip('show');
Comment on attachment 72815 [details] [review] Bug 20346 - New wording above the patron table on the patron page Untranslatable strings: + filtered = " starting with "; + } else { + filtered = " containing "; + } + filtered += "'" + $("#searchmember_filter").val() + "'"; These would also better written using _(" starting with '%s'").format(...) instead of concatenation. Same problems here: + filtered += " begins with " + "'" + $("#firstletter_filter").val() +"'"; + } else { + filtered = " begins with " + "'" + $("#firstletter_filter").val() +"'"; And here: + filtered += " with category " + "'" + $("#categorycode_filter").find("option:selected").text() + "'"; + } else { + filtered = " with category " + "'" + $("#categorycode_filter").find("option:selected").text() + "'"; And: + filtered += " in library " + $("#branchcode_filter").find("option:selected").text(); + } else { + filtered = " in library " + $("#branchcode_filter").find("option:selected").text();
The patch works as described. It's a good enhencement but in my point of view, the use of the filter block becomes too restrictive. For exemple, it's not possible once the patch is applied to search all the users using the same email adress if they have different surnames. This is a feature we use a lot and it would bothered me if we lose it. Is it possible to keep a "search" fonction if no research is made on the toolbar, instead of being only filter options ?
Created attachment 73520 [details] [review] Bug 20346 - Making JS strings translatable This is based on tester feedback in comments 7 and 8 Sponsored-By: Catalyst IT
I'm highly surprised because this patch is still "In discussion" but one of the proposed modification (remove 'search field' dropbox) is now applied on 18.05. I'm quite sad about that because, as I said on my comment in march, it was really useful for our local use, and I wasn't prepare to loose this option as there were no activity on that ticket since april. Can this modification come from anoter patch ? I didn't see which one it could be when I took a look to 18.05 release notes.
Is this still valid? I feel like the search filters are filtering on existing search results in master. Can someone please confirm?
(In reply to Aleisha Amohia from comment #12) > Is this still valid? I feel like the search filters are filtering on > existing search results in master. Can someone please confirm? I believe that the confusion has been removed by renaming the side filters to 'search for patron' and it will show your search term when entered in the search above first. And if you want to filter the search results, you can use the filters on top of the columns or the table one.