Bug 8887 - Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results)
Summary: Search preferences: Strange behaviour with exact matches (default instead of ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff Client (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-07 17:44 UTC by Marc Véron
Modified: 2014-12-07 20:02 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Wrong favicon and to many results with exact match (322.27 KB, image/jpeg)
2012-10-07 17:44 UTC, Marc Véron
Details
Bug 8887 Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results) (2.12 KB, patch)
2012-10-07 18:11 UTC, Marc Véron
Details | Diff | Splinter Review
Bug 8887 Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results) (2.17 KB, patch)
2012-10-07 19:23 UTC, Mirko Tietgen
Details | Diff | Splinter Review
Bug 8887: only display desired result when doing exact syspref search (2.16 KB, patch)
2013-08-12 16:23 UTC, Galen Charlton
Details | Diff | Splinter Review
Bug 8887: only display desired result when doing exact syspref search (2.26 KB, patch)
2013-08-16 16:12 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Véron 2012-10-07 17:44:21 UTC
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.
Comment 1 Marc Véron 2012-10-07 18:11:35 UTC Comment hidden (obsolete)
Comment 2 Marc Véron 2012-10-07 18:18:56 UTC
Mistaked with module, changed to Staff Client.
Comment 3 Mirko Tietgen 2012-10-07 19:23:18 UTC Comment hidden (obsolete)
Comment 4 Mirko Tietgen 2012-10-07 19:27:52 UTC
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 5 Paul Poulain 2012-10-22 15:12:16 UTC
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
Comment 6 Jonathan Druart 2012-10-24 15:02:27 UTC
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.
Comment 7 Marc Véron 2012-10-24 15:21:36 UTC
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
Comment 8 Galen Charlton 2013-08-12 16:23:37 UTC Comment hidden (obsolete)
Comment 9 Galen Charlton 2013-08-12 16:37:23 UTC
(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.
Comment 10 Kyle M Hall 2013-08-16 16:12:49 UTC
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.
Comment 11 Galen Charlton 2013-08-16 16:18:23 UTC
Pushed to master.  Thanks, Marc!
Comment 12 Tomás Cohen Arazi 2013-09-11 17:54:33 UTC
This patch has been pushed to 3.12.x, will be in 3.12.5.

Thanks Marc!
Comment 13 Chris Hall 2013-10-21 19:30:26 UTC
Pushed to 3.8.x, will be in 3.8.19.