[Koha-bugs] [Bug 10831] New: QueryParser requires that defaultSortField and defaultSortOrder be set to non-NULL values

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10831

            Bug ID: 10831
           Summary: QueryParser requires that defaultSortField and
                    defaultSortOrder be set to non-NULL values
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Searching
          Assignee: gmcharlt at gmail.com
          Reporter: gmcharlt at gmail.com
        QA Contact: testopia at bugs.koha-community.org

If QueryParser is enabled, the system preferences
defaultSortField/defaultSortOrder (and their OPAC kin
OPACdefaultSortField/OPACdefaultSortOrder) should not be set to NULL values. 
Otherwise, for searches where the sort order is not explicitly specified (e.g.,
searches made from the staff and OPAC global search box), the search can fail.

This is due to several slightly questionable coding constructs collaborating in
the confusion of both the user and the developer:

[1] If a default sort order is not set, catalogue/search.pl and
opac/opac-search.pl can end up setting the @sort_by array to (undef).  This is
because of the construct

@sort_by = $cgi->param('sort_by');

If the sort_by CGI parameter is not passed, the result is not an empty array,
it's an array containing one element whose value is undef.

[2] The following code in C4::Search::parseQuery in turn uses @sort_by to add
QP modifiers:

        if ( scalar(@sort_by) > 0 ) {
            my $modifier_re =
              '#(' . join( '|', @{ $QParser->modifiers } ) . ')';
            $query =~ s/$modifier_re//g;
            foreach my $modifier (@sort_by) {
                $query .= " #$modifier";
            }
        }

If the query is "history", the modified version becomes "history #" ... which
in turn results in a query that will not make sense to Zebra.

One solution is to push through a DB update that extends the fix for bug 8012
to  set the system preferences to sensible default values (probably relevance
descending) if they're currently NULL.  Note, by the way, that this means that
the bug manifests itself only in databases old enough to have been created
before the patch for bug 8012 was pushed.

Another part of the solution, however, ought to be make the code in question a
little more robust.

-- 
You are receiving this mail because:
You are watching all bug changes.