Bug 4221

Summary: defaultSortField & OPACdefaultSortField non functioning
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: System AdministrationAssignee: Sophie MEYNIEUX <sophie.meynieux>
Status: RESOLVED DUPLICATE QA Contact: Bugs List <koha-bugs>
Severity: normal    
Priority: P5 - low CC: fridolin.somers, koha.sekjal, stephane.delaune
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: Sponsored Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: proposed patch

Description Chris Cormack 2010-05-21 01:24:34 UTC


---- Reported by nengard@gmail.com 2010-02-18 20:21:34 ----

No matter what I change these values to my search automatically sorts by Relevance.



---- Additional Comments From ian.walls@bywatersolutions.com 2010-04-07 15:59:59 ----

For the staff client, all four values (defaultSortField, defaultSortOrder, OPACdefaultSortField and OPACdefaultSortOrder) need to be explicitly set.  Upon first installation, they are NULL, which prevents them from being respected in the staff client.  The dependence on OPACdefaultSortField and OPACdefaultSortOrder is erroneous and will be patched.

For the OPAC, only the OPACdefaultSort* values must both be set.  However, there is a security hole whereby anyone can activate any named TMPL_VAR in opac-results.tmpl by adding "&sort_by=TMPL_VAR" (try &sort_by=koha_spsuggest in any search for an example).



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4221 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4221

Actual time not defined. Setting to 0.0

Comment 1 Paul Poulain 2011-08-02 15:19:27 UTC
Nicole, just checked what ian said, it's still relevant I think.
Comment 2 Paul Poulain 2011-08-02 15:21:59 UTC
Created attachment 4809 [details] [review]
proposed patch
Comment 3 Paul Poulain 2011-08-02 15:23:14 UTC
This patch just fixes what Ian said. On an existing install it won't do anything.
Comment 4 Ian Walls 2011-08-02 16:31:39 UTC
I do not believe that the current form of this bug is a data issue; I'm seeing a newly upgraded library lose the default sort choice in both OPAC and staff client since they upgraded to 3.4, which makes me suspect a T:T error.  Explicitly resetting the sort values did nothing to fix the problem.
Comment 5 Paul Poulain 2011-08-03 07:26:38 UTC
Ian, I agree with you, there are probably 2 problems :
* the default value set to NULL. My patch address just this
* the sort order is not respected. I've checked on biblibre/master, and confirm we also have the problem, so it's not a new one.
Comment 6 Fridolin Somers 2011-08-22 09:20:19 UTC
(In reply to comment #5)
> Ian, I agree with you, there are probably 2 problems :
> * the default value set to NULL. My patch address just this
> * the sort order is not respected. I've checked on biblibre/master, and confirm
> we also have the problem, so it's not a new one.

Hie,
In patch, default value is "desc", but the choices are "dsc|asc".
Default value should be "dsc", without "e".

Regards,
Comment 7 Ian Walls 2011-09-02 13:13:35 UTC
I'm taking Fridolyn's comment as a serious issue with the patch, and marking as Failed QA.  If this is not actually a problem, please provide documentation that it can still work with the 'e' in 'desc'
Comment 8 Sophie MEYNIEUX 2012-06-10 15:43:02 UTC
Without applying any patch, I have tried to change the value of thoses sysprefs several times and search results seems to be correctly sorted.
Nicole, could you give more information if it still does not work for you ?
Comment 9 Fridolin Somers 2012-06-20 14:40:40 UTC
(In reply to comment #8)
> Without applying any patch, I have tried to change the value of thoses
> sysprefs several times and search results seems to be correctly sorted.
> Nicole, could you give more information if it still does not work for you ?

The problem only occurs on a fresh install.
The first modification of the syspref will set a value.
Comment 10 Fridolin Somers 2012-08-20 15:08:27 UTC

*** This bug has been marked as a duplicate of bug 8012 ***