Created attachment 12724 [details] Wrong favicon and to many results with exact match If searching a preference results in a exact match, the default favicon is displayed instead of the custom favicon. Additionaly, the list shows more entries than expected. E.g. if you do a search on "AddPatron", favicon is OK and the list shows just one entry ("AddPatronLists") If you do a search on the exact name ("AddPatronLists"), favicon is the default one and the list shows _all_ Patron preferences (instead of just this one). See screenshot attached.
Created attachment 12725 [details] [review] Bug 8887 Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results) Removed superfluous test on exact match in preferences.pl (with return straight out the loop) Test scenario: a) Make sure you have defined a custom favicon using syspref IntranetFavicon b) In sysprefs, do a search with partioal match (e.g. intranetcolor) -> Result shows one entry: intranetcolorstylesheet, and favicon (in browser tab) displays as expected. d) Do an exact search. e.g. intranetcolorstylesheet -> Result shows all Staff Client preferences. Favicon (in browser tab) falls back to the Koha default icon Apply patch, test again. Now d) behaves like b), favicon displays as expected.
Mistaked with module, changed to Staff Client.
Created attachment 12726 [details] [review] Bug 8887 Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results) Removed superfluous test on exact match in preferences.pl (with return straight out the loop) Test scenario: a) Make sure you have defined a custom favicon using syspref IntranetFavicon b) In sysprefs, do a search with partioal match (e.g. intranetcolor) -> Result shows one entry: intranetcolorstylesheet, and favicon (in browser tab) displays as expected. d) Do an exact search. e.g. intranetcolorstylesheet -> Result shows all Staff Client preferences. Favicon (in browser tab) falls back to the Koha default icon Apply patch, test again. Now d) behaves like b), favicon displays as expected. Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Tested with default favicon ('new' staff client favicon) where the same thing happened. This patch fixes the problem and establishes consistency for the presentation of syspref search results.
Comment on attachment 12725 [details] [review] Bug 8887 Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results) Patch obsoleted by the signed-off one
QA Comment: I did not test the original issue. But you change the behaviour of the results. Without your patch, if I search with an exact match, the result page display all the syspref for the module. With your patch, the page only contains 1 result. I don't know if it is what the users want. I would like to have others point of view. In discussion.
If we keep the original behaviour, somebody should track down why the wrong favicon is displayed. It is not only cosmetic. Such small glitches can be a hint for a bigger issue that could have an impact on other things. Marc
Created attachment 20278 [details] [review] Bug 8887: only display desired result when doing exact syspref search This patch fixes an issue where entering the complete name of a system preference when doing a syspref search in the staff interface resulted in the display of *all* preferences belonging to the desired one's module. Since providing a more specific search string should result in getting back more specific results, the previous behavior was not intuitive. Test scenario: a) In sysprefs, do a search with partial match (e.g. intranetcolor) -> Result shows one entry: intranetcolorstylesheet b) Do an exact search. e.g. intranetcolorstylesheet -> Result shows all Staff Client preferences Apply patch, test again. Now b) behaves like a). Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(In reply to Jonathan Druart from comment #6) > I don't know if it is what the users want. It is what *this* user wants -- this has been annoying me for years, albeit not enough to do anything about it. I do not find it intuitive that providing a more specific search string yields more hits, not fewer. The existing behavior was intentional -- see commit cdb3d52423f9 -- but IMO the "jump to preference" is only effective if the module (e.g., Circulation) has enough preferences to make the page long enough that the desired preference is scrolled to the top of the browser viewport. For most sysprefs, though, I end up having the scan the page for the one I just searched for, and it would be easier if the search just gave me only the one I was looking for. I recognize that opinions can differ on this, but thus far no contrary ones have actually been expressed. I've signed off on the patch and adjusted the wording of the commit description a bit. I did remove mention of the favicon, as I wasn't able to reproduce it and I think it's a moot issue. Status => Signed Off.
Created attachment 20427 [details] [review] Bug 8887: only display desired result when doing exact syspref search This patch fixes an issue where entering the complete name of a system preference when doing a syspref search in the staff interface resulted in the display of *all* preferences belonging to the desired one's module. Since providing a more specific search string should result in getting back more specific results, the previous behavior was not intuitive. Test scenario: a) In sysprefs, do a search with partial match (e.g. intranetcolor) -> Result shows one entry: intranetcolorstylesheet b) Do an exact search. e.g. intranetcolorstylesheet -> Result shows all Staff Client preferences Apply patch, test again. Now b) behaves like a). Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net> Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Passes koha-qa.pl, works as advertised.
Pushed to master. Thanks, Marc!
This patch has been pushed to 3.12.x, will be in 3.12.5. Thanks Marc!
Pushed to 3.8.x, will be in 3.8.19.