and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes the code from the search scripts into QueryBuilder
modules.
To test:
1 - Have a library group defined as a search group for both staff and opac
2 - Search on staff client and opac with that group limit and a single branch limit
3 - Note your results/counts
4 - Note the visuals of the search description
5 - Apply patch
6 - Repeat searches
7 - All should work as before
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
From
commit df97814f30
Bug 15758: Koha::Libraries - Remove GetBranches
+ selected_branchcode => ( C4::Context->IsSuperLibrarian ? C4::Context->userenv : '' ),
And
- [% PROCESS options_for_libraries libraries => Branches.all() %]
+ [%# FIXME Should not we filter the libraries displayed? %]
+ [% PROCESS options_for_libraries libraries => Branches.all( selected => selected_branchcode, unfiltered => 1 ) %]
The change in the pl is wrong as it should pass C4::Context->userenv->{branch},
but prior to this commit it seems that we didn't select the logged in
library anyway.
Looks like we should remove this code but preserve the current behavior and select "All libraries".
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In staff interface and OPAC, searching only zero leads to advanced search page.
Test plan :
1) Go to opac home page
2) Enter 0 into search field
=> Without patch you go to advanced search page
=> With patch you go to results page
3) Idem on staff interface
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
before this patch, the limit only applies to groups of libraries
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Syspref is now called SearchLimitLibrary, and the description better
explains what the feature does. It works with the advanced search on the
staff client and OPAC, and the masthead search on the OPAC when
OpacAddMastheadLibraryPulldown is enabled.
Sponsored-by: Catalyst IT
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Trying to make the code a bit more readable removing unecessary
variables and parenthesis.
Code is duplicated but no idea where we could move it to.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This commit allows librarians to choose whether they want to query the
homebranch, holdingbranch or homebranch AND holdingbranch when they set
a library or library group search condition in the staff client and OPAC
advanced searches.
Test plan:
1. Apply patches, update database, restart services
2. Set up a record with one item. Edit the item so that:
home branch = Branch A
holding/current branch = Branch B.
Note the barcode of your item.
3. Go to Administration -> Library Groups. Create a library group that
only contains Branch A.
= homebranch and holdingbranch =
4. Go to Administration -> System preferences and find the new
SearchLimitLibrary syspref. Confirm it is set to 'homebranch and
holdingbranch' by default. Keep this tab open.
5. Go to Advanced Search in the staff client in another tab. Under 'location and
availability', select your library group from the dropdown. Under
'search for', select the barcode option and enter your item's barcode.
6. Submit the search and confirm you are taken to your item as expected.
7. Go back to Advanced Search. Under 'location and availability', select
Branch A from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
8. Submit the search and confirm you are taken to your item as expected.
9. Go back to Advanced Search. Under 'location and availability', select
Branch B from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
10. Submit the search and confirm you are taken to your item as expected.
= homebranch only =
11. Go back to your System preferences tab. Set the SearchLimitLibrary
syspref to 'homebranch'. keep this tab open.
12. Go to Advanced Search in the staff client in another tab. Under 'location and
availability', select your library group from the dropdown. Under
'search for', select the barcode option and enter your item's barcode.
13. Submit the search and confirm you are taken to your item as expected,
because the syspref is set to homebranch and the library group contains our item's
homebranch.
14. Go back to Advanced Search. Under 'location and availability', select
Branch A from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
15. Submit the search and confirm you are taken to your item as expected.
16. Go back to Advanced Search. Under 'location and availability', select
Branch B from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
17. Submit the search and confirm you are NOT taken to your item and your item
does not show in the search results.
= holdingbranch only =
18. Go back to your System preferences tab. Set the SearchLimitLibrary
syspref to 'holdingbranch'. keep this tab open.
19. Go to Advanced Search in the staff client in another tab. Under 'location and
availability', select your library group from the dropdown. Under
'search for', select the barcode option and enter your item's barcode.
20. Submit the search and confirm you are NOT taken to your item and your
item does not show in the search results, because the syspref is set to
holdingbranch and the library group does not contain our item's holdingbranch.
21. Go back to Advanced Search. Under 'location and availability', select
Branch B from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
22. Submit the search and confirm you are taken to your item as expected.
23. Go back to Advanced Search. Under 'location and availability', select
Branch A from the individual libraries dropdown. Under 'search for',
select the barcode option and enter your item's barcode.
24. Submit the search and confirm you are NOT taken to your item and your item
does not show in the search results.
25. Repeat the above test plan but do your searching with the OPAC
advanced search.
Sponsored-By: Brimbank Library
Signed-off-by: Amandine Zocca <azocca@ville-montauban.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Deleting a patron or patron club causes server error on searching.
To recreate:
- create a club template
- create a club
- enroll a patron in the club
- from the clubs page, select Search To Hold for your club
- do a search, see that it says "Hold for [club name]" in your search results page
- go back to the clubs page and delete your club
- try to perform a search
=> Without this patch you get "Can't call method "name" on an undefined value at /kohadevbox/koha/catalogue/search.pl line 207"
Same when placing a hold for a patron (check the search result and the
detail pages)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Apply patch
2 - Search on staff and opac side
3 - Confirm you can paginate results
4 - Confirm you see 10 pages on pagination if under page 10
5 - Confirm you see 20 pages in pagination if over page 10
6 - Confirm you can go to first or last page
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
JD amended patch: perltidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Enable IntranetCatalogSearchPulldown
2 - Perform a search that brings you to a single title
3 - Note the search is not displayed on the details page
4 - Apply patch
5 - Repeat
6 - Note the search is retained on details page
7 - Try with different dropdown values and search terms
8 - Test search terms including accented characters etc
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Bug 23475: (follow-up) Fix selectors and stray use statements
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently we apply weighting to all searches except advanced search. The theory
being that when selecting indexes we don't want to apply weights. When searching
in ES weights are only applied to relevant results so it doesn't matter.
i.e. if weighting author*100 but searching subject, a term matching the subject search in author
is not boosted.
Given this, we should always apply weights, unless the user wishes not to
To test:
1 - Set some weighting
2 - Do some searches
3 - Note your terms and results, try advanced and regular searches specifying indexes or not
4 - Apply patch
5 - Note that opac and staff advanced search have option to apply weights
6 - Compare searches after the patch to see how weighting affects, it should be beneficial or not at all
Signed-off-by: Myka Kennedy Stephens <mkstephens@lancasterseminary.edu>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
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>
This patch adds the ability to jump back to the search result after a
record has been deleted.
Also it keeps the "browser" when all items are deleted from a
bibliographic record
Test plan:
- Start a new search
- Select a record with items
- Delete all the items
=> You still see the browser
- Delete the record
=> You are back to the adv search form but we new link "Go back to the
results" is present at the top of the page
Limitation: As we delete the record we do not longer know the offset,
we are back to the first page of the result list
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
commit 417553a9e4
Bug 12478: starting to add search to staff client
This commit added code related to the itemtypes to the advanced search, but this code already existed.
The weird bit is:
$template->param(advancedsearchesloop => \@advancedsearchesloop);
my $types = C4::Context->preference("AdvancedSearchTypes") || "itemtypes";
my $advancedsearchesloop = prepare_adv_search_types($types);
$template->param(advancedsearchesloop => $advancedsearchesloop);
We are passing twice advancedsearchesloop to the template.
Test plan (for QA):
Review the changes and confirm that we can safely remove this code
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Apply patch, update database
2 - Note new syspref 'DumpSearchQueryTemplate'
3 - Leave it off
4 - Enable DumpTemplateVariablesOpac and Staff
5 - Search on staff and opac
6 - View the source
7 - Search for 'search_query' - you shouldn't find it
8 - Enable the new pref
9 - Repeat, but you should find the query
10 - Test staff/opac search and advanced search, cataloguing search, authority search, authfinder search, adding to a basket form a new biblio
11 - All should work and show the query
12 - This will work under both ES and Zebra
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan
1. Set up a system with ElasticSearch
2. Set up or make sure ther are at least two branches
3. create a group of branches
4. make sure there are items associated with any library in the group
5. make a search in opac limited by the library group
6. make an advanced search in intra limited by the library group
7. change SearchEngine system preference to Zebra and repeat 5. and 6.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifes the process of searching for an existing record
to add to a basket. Now the search is performed as a keyword search in
the regular catalog rather than via a custom search script. Options are
added to the search results and detail pages to add results to an order.
This process follows the same pattern as the "Search to hold" feature:
When the search is initiated, a cookie is set with the requisite
information--in this case vendor id and basket number.
If the search results or bibliographic detail pages detect that a
"searchToOrder" cookie is present, the correct "Add order" link will be
shown. Like with the "search to hold" feature, the cookie expires in 10
minutes.
To test, apply the patch and log into the staff client as a user who has
permission to add to a basket in acquisitions.
- Go to Acquisitions -> Vendor -> Basket -> Add to basket.
- Using the "From an existing record" option, perform a search.
- On the search results page, test the "Add order" link which appears
with each result. Clicking the link should take you to the "New
order" page for the correct vendor and basket. The catalog
details section of the form should include the correct information.
- From the search results page view the bibliographic details page for
any record. There should be a new toolbar button, "Add order." Verify
that it works correctly.
- Test the same thing from all bibliographic detail pages: Normal,
MARC, Labeled MARC, ISBD, as well as the items page
(moredetail.pl).
- Test this process for both the locations in acquisitions where one
can add to an existing basket: Vendor search results and the basket
detail page
- Test the cookie timeout: Wait 10 minutes and perform another catalog
search. The "Add order" link should no longer be present.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Adds support for using the "scan indexes" action in advanced search by using faceting with a prefix filter. Requires that the field be set as facetable for anything to be found.
Test plan:
1. Apply patch
2. Go to advanced search and click "More options"
3. Select author as the search field, enter a last name and check "Scan indexes"
4. Perform search and observe the result list resembling scan results
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Generate a list of fields for the query_string query fields parameter,
with possible boosts, instead of using "_all"-field. Also add "search"
flag in search_marc_to_field table so that certain mappings can be
excluded from searches. Add option to include/exclude fields in
query_string "fields" parameter depending on searching in OPAC or staff
client. Refactor code to remove all other dependencies on "_all"-field.
How to test:
1) Reindex authorities and biblios.
2) Search biblios and try to verify that this works as expected.
3) Search authorities and try to verify that this works as expected.
4) Go to "Search engine configuration"
5) Change some "Boost", "Staff client", and "OPAC" settings and save.
6) Verify that those settings where saved accordingly.
7) Click the "Biblios" or "Authorities" tab and change one or more
"Searchable" settings
8) Verfiy that those settings where saved accordingly.
9) Try to verify that these settings has taken effect by peforming
some biblios and/or authorities searches.
Sponsorded-by: Gothenburg Univesity Library
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to place a hold for each member of a club in random order.
To test:
1) apply this patch
2) create 2 clubs, (club names should have some part in common, and some part different for each other)
3) in one of them add at least 6 members
4) enter patron clubs management and click on "Actions" button
SUCCESS.1 => club with members has a new action called "search to hold"
5) click on search to hold
SUCCESS.2 => in the list of bilios there appears an action called "Place hold for <club name>"
6) click on "Place hold for <club name>"
SUCCESS.3 => a new window appears where you can select pickup location (defaults to club's library, if any), and the list of members.
7) go back to the list of bilios in the catalog and click on "Forget <club name>"
8) click on "Holds" action of any biblio
SUCCESS.4 => a search box appears with two tabs: Patrons and Clubs
9) click on Clubs tab and search by the common part of clubs names
SUCCESS.5 => a list of clubs that matches the search appears. If you click on any of them, the same page as SUCCESS.3 appears.
10) go back to the search box in SUCCESS.4 and search by the different part of the name.
SUCCESS.6 => because there is only one club that matches search criteria, the same page as SUCCESS.3 appears;
11) Sign off
Sponsored-by: Southeast Kansas Library - SEKLS
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes the constraint of only passing 5 facets to the template unless the list is expanded, in fact, it removes the 'expanded' attribute from Search.pm
Now that all facets are passed to page it adds a 'show more' link at the bottom of lists and allows user to expand or collapse any facet set without reloading page.
Updated tests included.
To test:
1 - Perform an OPAC search that returns more than 5 of any given facet type
2 - Click the "Show more" link on the facets and see that the search is reloaded
3 - Apply patch
4 - Repeat search
5 - Note that you can click "Show more" without reloading page
6 - Test that page load is not greatly affected
7 - Ensure that all facet links function normally
8 - Ensure that facets are the same a prior to patch
9 - Repeat for staff client
10 - Prove t/Search.t
NOTE: This patch makes it much easier to see that there is an existing issue with marking the "active" facet. Ending punctuation seems to confuse the matcher.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Script search.pl checks OPACdefaultSortField and OPACdefaultSortOrder, but
shows defaultSortField and defaultSortOrder when using Advanced Search
in the staff client.
Test plan:
Apply the patch and then check that the Advanced Search uses
defaultSortOrder and defaultSortField sysprefs instead of the OPAC
sysprefs in the conditional. Check that sort behaviour in Advanced
Search still functions as expected. (It should do - this doesn't change
what displays, just improves consistency).
Sponsored-by: Catalyst IT
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
