LP1050043 was issued because attempting to sort the MARC expert search
results, in the staff client, caused the staff client to return to the
basic search page rather than sort the results.
To fix the sorting I had to modify two perl files.
metabib.pm had to be changed in a number of ways.
1. The way the sort works currently assumes the user is doing a full
text search. So, it passes in the values of titlesort and authorsort as
the sort variable in the URL. However, in the expert search, it is
looking for the values 'title' and 'author'. This resulted in the title
sort and author sort never being executed and returning the relevance
sort instead. I modified the search to use a regex instead of eq.
2. If a record has no value associated with it e.g. no 260 c for
pubdate, no 245 $a for title, no 1xx $a for author, then the SQL is
supposed to replace those values with either 'AAAA' or 'zzzz' depending
on the order of the sort. This should cause records without the
relevant sort values to be pushed to the bottom of the sort results.
But, the PgSQL function COALESCE, which is supposed to do the
replacing, does not do anything if no rows are returned for a record's
relevant value. To work around this, I surrounded the relevant values
with the MAX() function call, which returns NULL if no row is returned.
Because author sort works on any 1xx value, it sorts those values in
numerical order when there is more than one 1xx in a record. This
requires the use of an ORDER BY statement, which seems to nullify
the effect of MAX(). So, I had to move the MAX() into a second SELECT
statement in the case of author sort.
3. I added the variables number_default_sort and string_default_sort
to the metabib code because the current code hard codes values of
'9999' and 'zzzzzzzz' into the sort.
Search.pm had to be changed to pass the sort values from the TPAC
into the relevant sort subroutines. This was done with the addition of
an $arghash variable that checks the cgi parameters for the sort
variable.
As well, Expert search puts the tag and _special params in the
search form. This causes all other searches to perform Expert searches
afterwords. To fix this, Search.pm is modified to look for an empty
query value before it conducts an Expert search. If it is empty and
the Expert search variables are present, then the Expert search is
performed. Otherwise, a normal search is done.
Finally, to fix the problem reported by LP1050043, I had to modify
searchbar.tt2. Currently, searchbar.tt2 does not have the values from
the Expert search entered into the <form> where the sort functionality
is located. This means, when a sort option is chosen, the TPAC no
longer knows which values were used for the Expert search.
This is not obvious at first because after choosing to sort, the
user is returned to a page where the URL has the Expert search values
in it. This happens because the sort is submitting a form without a
query value, so the TPAC redirects the user to the referring page,
which is the initial Expert search.
To fix this, I added the Expert search values as hidden variables
into the <form> where the sort functionality is located. I also
removed the use of the "_adv" hidden variable from the <form> when
not in the advanced search.
[LP1094269] Retrive past 100 records in Expert Search
Currently, when paging through the results of the Expert search, the
system will not return more than 100 records. Going past page 10
causes a no results screen.
This is due to the offset and limit values not being passed into the
argument hash used to create the SQL for the search. Once the SQL
returns, it returns record ids within the range of the offset and
the limit. So, if the offset is 100 and the limit is 10, the record
ids for search results 100 to 109 are returned.
But, because offset and limit are not being passed into the arghash,
they default to 0 and 100 respectively. This means the first 100
records are always returned regardless of where in the search pages
you are viewing. These 100 results were then pruned to the relevant
10 results in Biblio.pm. However, if the offset starts beyond 100
then no results are returned because the results passed 100 are not
returned by metabib.pm.
This commit passes the offset and limit as arguments in the search
hash. It also removes offset and limit as parameters of the
search.biblio.marc call. Because offset and limit are needed in the
arghash to limit the number of records returned, it is better to
pass them only via the arghash to ensure that no more than the
necessary number of records are returned.
Offset and limit could be kept as parameters, but it would require
modifying metabib as well to look for those parameters, so I think
forcing the Expert search to pass them as argument parameters is the
better option.
As well, this commit removes the pruning in Biblio.pm that was based
on the offset and limit because that is handled in metabib.pm now
that offset and limit are being supplied in the argument hash.
I have checked the source code and the marc_search function in
Biblio.pm is only called via the Expert search in
WWW/EGCatLoader/Search.pm, so modifying Biblio.pm in this manner
will only affect the Expert search and nothing else.
Signed-off-by: Liam Whalen <liam.whalen@bc.libraries.coop> Signed-off-by: Sarah Childs <sarahc@zionsvillelibrary.org> Signed-off-by: Ben Shum <bshum@biblio.org>
projects / Evergreen.git / commit