This patch also fixes add the term in the search input
Test plan:
Enable IntranetCatalogSearchPulldown
Search for a term using the search input in the header (simple search)
Re-do selecting different indices
The selection must retain on the search result page.
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch was generated using codespell
Test plan:
Read through changes and confirm they make sense
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=21706
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Rebased-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Ere Maijala <ere.maijala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The idea is the following: if some search field(s) are weighted in
search engine config page, Koha will query ES on all fields plus those with
the coresponding weights. Else, search is done on the entire record with
no weighting. The advanced search page is unaffected by these changes
Test plan (having Koha working with Elasticsearch):
- apply this patch
- have some weights defined for various fields
- try searches from the search bar and from the advanced search page
- confirm weighting affects the relevancy (in expected ways)
e.g.
1. search for 'a' from advanced search, note results
2. give 'title' a weight
3. search for 'a' using the simple search bar
4. results with 'a' in the title should now be more relevant
- confirm search results on advanced search page are unaffected
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Rebased-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Ere Maijala <ere.maijala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Edit: Fixing merge conflicts in
- t/db_dependent/Items.t
- t/db_dependent/Search.t
- C4/Search.pm
Changes the API for calling GetHiddenItems and all the places in the code that call it. This is to allow borrower categories to be passed in.
Adds an OpacHiddenItemsExceptions syspref to allow certain borrower categories to be able to see items, even if they are marked hidden by OpacHiddenItems
To test:
1) Make two borrowers, one in a category that should see everything (ie Adult), and another in a category that should only see certain things (ie Adult - exceptions)
2) Add the borrower that can see everything (the Adult) to OpacHiddenItemsExceptions
3) To the OpacHiddenItems syspref, add an item type (ensure that you have some records that fall under this type in your library).
4) Log in as the borrower that should only see certain things (Adult - exception)
5) Do a search, filtered to show records which are the item type that you specified in the OpacHiddenItems syspref. No records should show for this borrower as this item type is hidden to them.
6) Log in as the borrower that should see everything (Adult)
7) Do the same search. There should be results from this search, as this borrower category has been specified as an exception to the hidden items
Signed-off-by: Claire Gravely <c.gravely@arts.ac.uk>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This avoid hardcoding '10000' in two different places and allow users to
adjust this setting.
Also, this patch fixes a bug when the search return less than 10000
results
Test plan:
1. Do a search that returns 10000+ records.
2. Note the warning above the pagination buttons
3. Go to the last page, no error
4. Change the ES setting:
curl -XPUT http://elasticsearch/koha_master_biblios/_settings -d \
'{"index": {"max_result_window": 20000}}'
5. Do another search that returns more than 10000 but less than 20000
6. Note that the warning does not show up
7. Go to the last page, still no error
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
https://bugs.koha-community.org/show_bug.cgi?id=19502
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch is to avoid hitting an error page. We should eventually make the
max number returned configurable for ES.
To test:
1 - Have Koha running ES with 10,000+ records
2 - Search for '*'
3 - Click 'Last' to view last page of results
4 - 'Cannot perform search' error
5 - Apply patch
6 - Search again
7 - View 'Last' page
8 - No error, you go to the last of 10000
9 - Note the warning above the pagination buttons
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In the last patches of bug 16735, we completely broke the feature!
The limit is using library_groups.id instead of branches.branchcode.
Test plan:
Create a group of library with the search feature
Search (OPAC and staff interfaces) using this limit
=> Without this patch you will see that the generated search query does
not contain branchcodes
=> With this patch applied you will see the branchcodes
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1. Start a search from intranet
2. See several warnings in logs
3. Apply patch (&& reload starman)
4. Start a new search
5. Confirm that warnings are gone and that the search still works
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Apply this patch set
2) Note your existing search groups have been ported over to the new
__SEARCH_GROUPS__ group if you had any
3) Create the group __SEARCH_GROUPS__ if one does not already exist
4) Add some first level subgroups to this group, add libraries to those groups
5) Search the library group searching in the intranet and opac
6) Note you get the same results as pre-patch
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
- Check that it now says 'use Modern::Perl;' and not 'use strict; use
warnings;' in the following catalogue perl scripts.
MARCdetail.pl
export.pl
image.pl
imageviewer.pl
issuehistory.pl
labeledMARCdetail.pl
moredetail.pl
search.pl
showmarc.pl
updateitem.pl
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch
- fixes callnum and sn
- Removes unecessary syspref transmission to the template.
As the template directly reads the syspref
Test plan:
1. Set sysprefs IntranetCatalogSearchPulldown and
IntranetNumbersPreferPhrase to true
2. Go to staff:/cgi-bin/koha/catalogue/search.pl
3. "search for" → "call number" and write anything that won't match a
call number in the field
4. Then you should see
«No results match your search for 'callnum,phr: [...]»
5. Go to the staff homepage
6. Click on "Search the catalog"
7. Do the same search as previouly
8. Then you should see
«No results match your search for 'callnum,wrdl: [...]»
This shows that IntranetNumbersPreferPhrase isn't honored
9. Apply this patch
10. Redo the same two searches and see that phr will now be always used.
So IntranetNumbersPreferPhrase is honored
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Have changed
my $last_page = $pages * ( $results_per_page - 1 );
to
my $last_page = ( $pages - 1) * $results_per_page;
which seems to fix the 'last' button offset! (Comment 10)
Will add the box to jump to a page in a separate patch.
Adding the pagination to the top on the staff client will be dealt with
in Bug 18916 as it is slightly out of the scope of this bug.
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
See Comment 8.
Test:
When on first page of results, confirm that the 'First' and 'Previous'
buttons do not show. Confirm they come back on the second page and every
page after.
When on last page of results, confirm that the 'Last' and 'Next' buttons
do not show. Confirm they come back on all previous pages.
Check on both staff side and OPAC.
Sponsored-by: Catalyst IT
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds first and last page buttons to the pagination at the
bottom of a page of catalog search results.
To test:
1) Apply patch
2) Do a number of searches
3) For each search, ensure that the first and last page buttons work as
expected
Sponsored-by: Catalyst IT
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There was a bug that meant a very large offset in the search params
will cause the search script to run forever (or long enough to crash
the machine)
To test
1/ Get ready with sudo top so you can kill the thread before it causes
your machine to OOM
2/ Hit a page like yourdomain.com/cgi-bin/koha/opac-search.pl?q=1&offset=-9999999999999999999
3/ Notice the process runs for a long time
4/ Kill the process
5/ Apply the patch
6/ Hit the page again, notice the it loads (offset is set to zero)
7/ Do the same to search in the staff client
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: changed -2 to 0 in opac-search.pl.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the period is entered without spaces wrapping the hyphen
You can't get any result
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
I can't reproduce the error, search still works after applying the patch
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In Staff client, the advanced serach form does not display the
translations of item types.
(Note: It is not necessary to have translations installed to verify
this bug.)
Prerequisites:
- Go to Home > Administration > Item types administration
- Edit e.g. item type "BK" (Book)
- Near "Description", click link "Translate into other languages
- If you have other languaes installed, add translatons for those
- If you have an Englis only installation, add a "translation" for
English, make sure that you can identify it while testing (I
used "BOOOOOOOOOOOOKS")
Verify:
- Go to Home › Advanced search
- Verify near "Limit to any of the following" that the description for
itemtype BK reads "Book" instead of "BOOOOOOOOOOOOKS"
Test:
- Apply patch
- Verify that the item type description now reads ""BOOOOOOOOOOOOKS"
- If you have a multi language installaton, verify that item types
you translated display as appropriate
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If there was more than one search term you could see that that it
was url encoded. Also problems with search terms with umlauts and
other diacritics.
Patch should fix that.
https://bugs.koha-community.org/show_bug.cgi?id=17074
Signed-off-by: Marc <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The 'scan indexes' search that can be reached from the
advanced search has 2 problems to begin with:
- The search term you searched for is not displayed
in the input field.
- The links in the result list are missing the index
and because of that, are not giving the correct results.
To test:
- Go to the advanced search, select an index to search in
- Enter a search term and check 'scan indexes'
- Submit search
- Check if the search term is visible in the input box
- Check if the result links contain your selected index
and give you correct results (count and the number of
results should match)
Tested both patches together, works as expected.
Signed-off-by: Marc <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds an "add to cart" link to each line of search results in
the staff client.
To test, apply the patch and clear your browser cache if necessary.
- Enable the intranetbookbag system preference.
- Perform a search which will return multiple search results.
- Each result should have an "Add to cart" link.
- Clicking the "Add to cart" link should add the title to the cart,
triggering the correct pop-up message and changing the link to read
"In your cart (remove)."
- Clicking the "remove" link should remove the title from your cart
and trigger the correct messages.
- Add multiple titles to your cart and perform the same search again.
Each result should correctly indicate which titles are already in your
cart.
- Open the cart popup window.
- Check the checkbox for one or more titles in your cart and choose
"Remove." The titles should be removed, and the "In your cart" label
in the search results page should reflect that the titles are no
longer in the cart.
- Choose "Empty and close." All titles in the parent page should now
indicate that they are not in the cart.
- Disable the intranetbookbag preference and confirm that the "Add to
cart" links are no longer there.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch does the same as the previous one, but affects lines which
have not been caught by the regex.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This reverts commit cd4905c2969b067476881016d0b03271f0bcc7c8.
This commit caused an error in C4::Search::GetFacets when running in
zebra mode.
Conflicts:
Koha/SearchEngine/Elasticsearch/Search.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This allows sorting to be configured within a field. For example, while
many values are included for search on author, sorting should only be
done on the main entry values. This permits that by have a sort value,
which can be true, false, or null. true and null are pretty much the
same, but false means that a field isn't available for sorting on. By
default (null), fields can be sorted on.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
* Use ->id instead of ->branchcode when possible to eliminate use of that nomenclature
* Fix bad use of ->branchcode to ->{branchcode} for unblessed hashref version of Koha::Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
C4::Branch::GetBranchesInCategory can be replaced with
Koha::LibraryCategory->libraries
Test plan:
1/ Define some 1+ group of libraries with 1+ libraries each
2/ Go on the advanced search (OPAC and Staff) and select a group of
libraries
3/ The result should be consistent and only include record from these
libraries
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test plan
1/ enable OpacAddMastheadLibraryPulldown
2/ Defined a group of libraries as searchdomain
and tick 'show in pull down'
3/ At the OPAC, go on the advanced search form, limit by the group of
libraries you have just created.
4/ The group should be selected by default in the dropdown list
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
http://bugs.koha-community.org/show_bug.cgi?id=15294
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch removes code related to stopwords usage. The following methods are removed:
C4::Search->remove_stopwords
C4::Context->stopwords
C4::Context->_new_stopwords
And the buildQuery API was changed (removed the \@removed_stopwords return value).
A follow-up is provided for database changes, to make rebasing easier.
To test:
- Apply this patch
- Do some searches in both intranet and opac interfaces
- Nothing should break
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
remove superfluous second declaration of template, borrowernumber and
cookie which are never used
Also removed the variables @results and @results_array which are
declared but not used
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
As suggested by Colin, perl -wc catalogue/search.pl doesn't complain
anymore after applying the patch. perlcritic confirms the 2 variables
were unused.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch fixes:
- reports/bor_issues_top.pl
- sort order
- adv search and search results
- opac-topissues.pl
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1/ update the Schema (misc/devel/update_dbix_class_files.pl)
2/ Translate templates for some languages (es-DE, de-DE for instance)
3/ Enable them in the pref (search for 'lang') for the staff interface
4/ Go on the item type admin page (admin/itemtypes.pl)
5/ Edit one
6/ Click on the 'translate for other languages' link
7/ You are now on the interface to translate the item type's description
in the languages you want. So translate some :)
8/ Go back on the item type list view (admin/itemtypes.pl)
9/ You should see the original description (non translated)
10/ Switch the language
11/ You should see the translated description in the correct language.
If the description is non translated, the original description is
displayed.
12/ On the different page where the item type is displayed, confirm that
the translated description appears.
Think further / Todo:
1/ Update all occurrences of the item type's description (DONE)
2/ Implement for authorised values
3/ Implement for syspref value (at least textarea)
4/ Implement for branch names
5/ Centralize all the translation on a single page in the admin area
...
N/ Implement a webservice to centralize all the translations and give
the ability to sync the item types/authorised values description with
the rest of the world (push and pull).
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 10404 adds the use of String::Random to catalogue/search.pl but bug
11369 removes it without removing the import line.
Test plan:
git grep String::Random catalogue/search.pl
should not return anything
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Note that this does not appears at the OPAC.
We will need 2 different testers here, the results seem to depend on the
Encode version.
0/ Determine your Encode version (`pmvers Encode`).
If you have 2.60:
1) /cgi-bin/koha/catalogue/search.pl?q=ééé&op=Submit
You should get
" No results match your search for 'kw,wrdl: ���' in my library Catalog."
2) /cgi-bin/koha/catalogue/search.pl?q=ກ
You should get
Cannot decode string with wide characters at
/usr/lib/i386-linux-gnu/perl/5.20/Encode.pm line 215.
If you have <2.60 (? not sure here):
1) /cgi-bin/koha/catalogue/search.pl?q=ééé&op=Submit
You should not get encoding problems.
2) /cgi-bin/koha/catalogue/search.pl?q=ກ
You should not get encoding problems.
Apply this patch, try again 1 and 2.
If the Encode version is >=2.60, the encoding issues should be fixed.
If not, please detail if there are any regression.
NOTE: Tested on Ubuntu 14.04, Debian 8, and Debian 7. See comment #3.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
This patch changes one small line in catalogue/search.pl and opac/opac-search to sort facets by:
facet_label_value
instead of
facet_title_value
To test:
1 - Perform a search with results in two branches e.g. Centerville (code CPL) and Fairfield (code FPL)
2 - Notice that branch facets appear correctly sorted
3 - Rename the branches Centervile->Zebra and Fairfeild->Aardvark (but don't change codes)
4 - Repeat original search
5 - Note that branch facets are no longer correctly sorted
6 - Apply patch
7 - Repeat search
8 - Facets should be correctly sorted
9 - Test in both staff and opac search
10 - Ensure there are no unintended consequences/regressions
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, staff AND opac
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
