Test plan:
Search for something
click on a facet with diacritic
click on another facet
remove the facet with diacritic
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When OpacBrowseResults syspref is on, the detail page contains a results browser.
When search terms contains non-ASCII character, the search query is not well encoded in this browser.
This patch adds the URI-coding to search terms into session to avoid any encoding problem with diacritics and URI specific characters like ?,& ...
So that TT parameter 'busc' is already URI encoded and can be used to recreate seach URL.
Test plan :
- Set OpacBrowseResults on
- At OPAC, perform a search with a diacritique. For example 'déjà'
- Go to detail page of a result
=> You see browser under "Browser results"
- Click on "Back to results"
=> You get same results and same search term with correct encoding
Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug still present on master. I note that latin characters are taken by ISO-8859-1 encoding
(Perl's default) and that's why real UTF8 ones don't break (Perl notices they are UTF-8).
The prefs language and opaclanguages used the comma to separate the
different values.
The new prefs OpacAdvSearchMoreOptions and OpacAdvSearchOptions should
do the same.
To reproduce the issue: update the language pref (or opaclanguages) and
refresh the page.
=> The pref values are not checked anymore and the language selection
(bottom of the page) does not appear.
Test plan:
1/ Verify that the behavior described above is fixed.
2/ Verify that the original test plan of bug 9043 still passes.
Note: The 2 OpacAdvSearchMoreOptions and OpacAdvSearchOptions pref
values are overwritten but the feature have just been pushed recently.
It should not affect a production environment.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I was able to reproduce the issue and verify that this patch corrected
the problem. Langage selection and OpacAdvSearchOptions worked
correctly.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds 2 new sysprefs: OpacAdvSearchOptions and
OpacAdvSearchMoreOptions.
These sysprefs are multivalued and you can add or remove some elements on
the adv search page.
This patch allows to display/hide some entries in the advanced search
page at the OPAC.
On this way, it is possible to configure the search options to display.
Test plan:
1/
Fill OpacAdvSearchOptions with Item types and Languages.
Fill OpacAdvSearchMoreOptions with Item types, Languages and Location.
On the advanced search page, verify the Location is only displayed for
the "More options" view.
2/ Try different settings for these prefs
3/ Remove all entries for the OpacAdvSearchMoreOptions and verify that
the "More options" does not displayed additional options.
4/ Remove all entries for the OpacAdvSearchOptions and verify that the
"normal view" does not displayed any options.
Note that this patch only affects the bootstrap theme.
Signed-off-by: Koha Team Lyon 3 <koha@univ-lyon3.fr>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since nobody is currently working on the zebra layer introduced by bug
8233, Solr won't never work.
Some code has been introduced in 3.10 to prove several search engines
can cohabit into Koha but no help/fund has been found to go ahead.
It is useless to keep this code and to maintain an ambiguous situation.
I think the indexes configuration page could be restore later if someone
else introduces a new search engine into Koha.
Test plan:
Look at the code introduced by bug 8233 and verify all is removed.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch affects only the area displayed on Advanced Search
by setting the AdvancedSearchTypes OPAC system preference
accordingly. Prior to this patch, no filtering based on
OpacHiddenItems was done. This patch determines if itemtypes,
collections, or shelving locations are hidden and prevents
them from being shown.
TEST PLAN
---------
1) Back up your DB (always handy)
2) Set the Searching system preference AdvancedSearchTypes to:
'itemtypes|ccode|loc' (without the single quotes).
3) Set the OPAC system preference OpacHiddenItems to include the
lines:
itype: [{list of itemtype codes separated by commas}]
location: [{list of comma delimited shelving location codes}]
ccode: [{list of comma delimited collection codes}]
Make sure to exclude one value for each, so there will be at
least one known thing on each tab.
4) Open the OPAC.
5) Click on 'Advanced Search'
-- three tabs appear: Itemtypes, Collection, Shelving location
-- Everything is visible
6) Set the Searching system preference AdvancedSearchTypes to:
'itemtypes | ccode | loc' (without the single quotes).
7) Refresh the OPAC.
-- There will be three tabs, but ugliness ensues.
8) Apply the patch
9) Refresh the OPAC.
-- You will see: Itemtypes, Collection, Shelving location
-- Only excluded values from OpacHiddenItems will be seen.
10) Run koha qa test tools
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Small rewording in comment only.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we're using the $query_type variable to detect if this pre-built
query is PQF, we need to use PQF syntax (rather than QueryParser
syntax) when adding to the query. I've made a lot of notes of somewhat
incoherent notes on Bugzilla talking about PQF, CCL, and QP syntaxes,
but I'm hoping to refine these notes on a wiki page for future
reference.
_TEST PLAN_
1) Set 'Suppress in Opac' (ie 942$n) to 1 for one record
2) Re-index Zebra
3) Set 'OpacSuppression' to 'Hide'
4) Set 'UseQueryParser' to 'Do not try'
5) In the staff client, do a search that will return that suppressed
record as well as a few records that are NOT suppressed
6) Note that you can return that suppressed record in the staff client
7) Do the same search in the OPAC
8) Note that the suppressed record doesn't appear
9) Set 'UseQueryParser' to 'Try' && re-run the OPAC search
10) Note that no results appear (the logs will probably mention a
ZOOM error)
11) Apply patch
12) Re-run the OPAC search
13) Note that the suppressed record doesn't appear, and that the
not suppressed records are showing (it's important that you are
getting some results...as ZOOM errors are silent in the UI).
14) Set 'UseQueryParser' to 'Do not try'
15) Re-run the search
16) Note that the suppressed record doesn't appear, and that the
not suppressed records are showing
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No koha-qa errors.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described - hidden records are hidden.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
OpacSupressions manipulates the query string after the buildQuery
call and so breaks with queryParser enabled. This patch adds
checks for queryParser and manipulates the query before passing it
to buildQuery if it is enabled, but leaves the post buildQuery
manipultation when queryParser is disabled
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Adding a sing after test
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes the use of smartmatch operators in the search code.
Regards
To+
Edit: this revision uses 'grep' instead of Lists::MoreUtils::any
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Tested search, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When searching (at the OPAC or pro), facets can be enabled but never
disabled. So a user is obliged to relaunch the search.
This patch adds a new link "[x]" at the right of each selected facet.
This link relaunch the search without this facet.
Test plan:
- Launch a search (OPAC and pro)
- Enable some facets
- Disable some facets
Signed-off-by: sonia bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patches pass all tests and QA script. Nice feature!
Tested in Boostrap and Prog, adding end removing multiple
facets in different sequences, adding and removing the
availability limit.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Also store interface (intranet, opac) in context to not have to pass it
as parameter.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Like biblio, this feature provides an authority search history.
This history is available for connected and disconnected user.
If the user is not logged in Koha, the history is stored in an
anonymous user sessin.
The search history feature is now factorized in a new module.
This patch adds:
- 1 new db field search_history.type. It permits to distinguish the
search type (biblio or authority).
- 1 new module C4::Search::History. It deals with 2 different storages:
DB or cookie
- 2 new UT files: t/Search/History.t and t/db_dependent/Search/History.t
- 1 new behavior: the 'Search history' link (on the top-right corner of
the screen) is always displayed.
Test plan:
1/ Switch on the 'EnableOpacSearchHistory' syspref.
2/ Go on the opac and log out.
3/ Launch some biblio and authority searches.
4/ Go on your search history page.
5/ Check that all yours searches are displayed.
6/ Click on some links and check that results are consistent.
7/ Delete your biblio history searches.
8/ Delete your authority searches history searches.
9/ Launch some biblio and authority searches
10/ Delete all your history (cross on the top-right corner)
11/ Check that all your history search is empty.
12/ Launch some biblio and authority searches.
13/ Login to your account.
14/ Check that all previous searches are displayed.
15/ Launch some biblio and authority searches.
16/ Check that these previous searches are displayed under "Current
session".
17/ Play with the 4 delete links (current / previous and biblio /
authority).
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All patches together pass QA script and tests.
Also, new tests in t/db_dependent/ pass.
Tested in all 4 OPAC themes, being logged in and anonymous.
Anonymous search history will be appended to personal search
history after logging in.
Also verified that cleanup_database still purges search history,
now also including the authority searchs.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes the following issue: in installations that are using
zebra DOM indexing for bibliographic records, tag searching in OPAC
doesn't work properly (clicking on any tag in OPAC leads to "404 error").
To test: ensure that with patch applied:
1) problems with tag searching get resolved for [some] test
configuration with biblio DOM indexing enabled,
2) there are no apparent tag-searching-related regressions in OPAC,
in some yet another test installation configured with legacy
(grs1) indexing mode for biblios.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In Advanced Search, the list of available language is long and will only
get longer. For a library offering books in 2-3 languages, that is
offering too many options to the user (most of the small libraries we
deal with only offer documents in two languages).
Code changes:
Languages.pm: Extract getAllLanguages to make a more customizable
getLanguages (have getAllLanguage call it, so rest of codebase is
oblivious to the change). Build array returned based on system pref if
corresponding argument is set.
search.pl and opac-search.pl: call getLanguages instead of
getAllLanguages.
TESTING
0) All language codes are iso 639-2 (three characters)
1) in OPAC, Advanced search, open Language box, acknowledge 30+ items.
2) in Intranet, go to system preferences AdvancedSearchLanguages,
enter "ita|eng"
3) back in OPAC, refresh screen, acknowledge only Italian and English
are listed.
4) in Intranet, click Search then click "More options" to make the
Language box appear. Acknowledge limited options.
5) Regression Test: Back to the preference, empty the field then save.
Go back to the OPAC and Intranet search, refresh the page, then the
Language drop-box will now contain 30+ items.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If hidelostitems is enabled, and the result of an opac search is a single
lost item, then the OPAC will display a 404 error, rather than a
"no results" screen.
Test Plan:
1) Catalog a record/item such that it is the only result for some search
e.g. Give it the title 'zxcvb'
2) Enable hidelostitems
3) Mark this item as lost
4) Perform an OPAC search that should result in a redirect to this record
5) Notice you a redirected to a 404 error
6) Apply this patch
7) Repeat step 4
8) Note you new get a "No results found!" page instead
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Michot <nmichot@voila.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- Remove unit tests for ParseSearchHistoryCookie, which doesn't exist
anymore
- Add unit tests for ParseSearchHistorySession and
SetSearchHistorySession
- Remove/Modify comments about search history cookie
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Tests fixed and moved, and comments tidied up
Signed-off-by: Charlene Criton <charlene.criton@univ-lyon2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Storing search history into cookie can cause problems, due to the size
limitation of 4KB.
The solution here is to store search history into the CGI::Session
object, so there is no size limitation (but anonymous search history
still remember up to 15 requests max.)
Test plan:
- Go to OPAC in anonymous mode.
- Check that the "Search history" link is *not* shown in the top right
corner of the page
- Make some searches on /cgi-bin/koha/opac-search.pl
- The "Search history" link should appear. Click.
- Your search history should be displayed.
- Try to log in with invalid username/password
- Go back to search history, it's still there
- Now log in with valid username/password
- Your anonymous search history should be saved into your own search
history.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Restoring original sign offs and comments below
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors
Well, search history saving is similar before and after patch.
i.e. anonmymous search is saved when user logs in, but cookie
KohaOpacRecentSearches is empty.
Shows current an previous session searches
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
All tests and QA script pass, works as described.
Signed-off-by: Charlene Criton <charlene.criton@univ-lyon2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test in OPAC:
* With the OPAC System Preference EnableOpacSearchHistory set
to Keep, a simple search triggers the warning patched on
line 626 of opac-search.pl
* Selecting a search result item with no Collection Code
set triggers the warning patched on line 576 of opac-detail.pl
* Have an item with Collection Code. Check that the Collection
Code shows.
* Collection Code is set by editing an item in the staff client
(952$8)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Show any relevant results from the OverDrive ebook/audiobook service
on the OPAC search. This is done by showing a link with "Found xx
results in the library's OverDrive collection" at the top of search
results and linking to a page that shows the full results.
This requires an OverDrive developer account, and is enabled by
setting the OverDriveClientKey and OverDriveClientSecret
system preferences. In addition, this patch adds the
OverDriveLibraryID system preference.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Henry Bankhead <hbankhead@losgatosca.gov>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Remove uncalled sub GetCcodes
Also remove comment in opac-search.pl which is
remaining reference to it and serves no
useful purpose
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Add validation of the value of the KohaOpacRecentSearches. In
particular, this patch avoids the generation of an internal server
error when the OPAC is presented with an old cookie that uses the
old Storable-based serialization.
This patch also moves parsing of the cookie value into a
new routine in C4::Auth, ParseSearchHistoryCookie, and adds
a test case.
To test (in conjunction with the previous patch):
Exercise the OPAC search history functionality, after
turning on the EnableOpacSearchHistory syspref:
- As an anonymous user, conduct a variety of searches,
including ones that include non-ASCII characters
- Check the search history and verify that all searches
are listed
- Apply this patch and the previous one.
- Do *not* clear the KohaOpacRecentSearches cookie
- Check the search history and verify that no searches
are listed any more
- As an anonymous user, conduct a variety of searches,
including ones that include non-ASCII characters
- Check the search history and verify that all searches
are listed
- Log into the OPAC
- Verify that current and past searches are listed in
search history.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
Exercise the OPAC search history functionality, after
turning on the EnableOpacSearchHistory syspref:
- Clear the KohaOpacRecentSearches cookie
- As an anonymous user, conduct a variety of searches,
including ones that include non-ASCII characters
- Check the search history and verified that all searches
are listed
- Log into the OPAC
- Verify that current and past searches are listed in
search history.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test
1/ logout
2/ search "bar" (added to the history)
3/ search "féé" => history is empty
Apply patch
1/ logout
2/ search "bar" (added to the history)
3/ search "féé" => added to the history
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The prototype is not consistent, GetBranchCategory should return only 1 result
and GetBranchCategories should not have a categorycode argument.
This patch fixes that.
Test plan:
1/ Try to add/remove/modify a library.
2/ Add some groups
3/ Add these groups to a library
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch groups all loops on the new_results array into one.
It is useless to loop on the same results array several times.
Test plan:
Quite hard to test all cases.
This patch deals with 5 sysprefs:
COinSinOPACResults, Babeltheque, TagsEnabled, TagsShowOnList and
OpacStarRatings.
Try to enable/disable all of them and verify there is no difference with
and without this patch.
The only different will be: The Babeltheque information should be displayed
even if the COinSinOPACResults syspref is disabled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This revised patch works fine for me, thanks.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Verified following system preferences still work as expected:
- COinSinOPACResults on/off
- TagsEnabled, TagsShowOnList, TagsInputOnList on/off
- OpacStarRatings
Couldn't test Babeltheque functionality as this requires an account.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For reasons I cannot fathom, the split() in handling multi-branch
limits was not coming up with a valid search group code. Replacing
the split() with a substr() and creating the CGI parameter as a string
rather than as an arrayref fixes the problem. This problem may not
affect all installations, since I tested this exact feature just under
two months ago and it worked fine, and none of the relevant code has
been changed since then that I can see.
To test:
1) Create search group, and add at least one library to it, in
/cgi-bin/koha/admin/branches.pl
2) Apply patch
3) Try doing a search limited to your search group, making sure that
the search will match items that belong to a library in the search
group
4) Sign off
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
I have failed to recreate the problem on three different dev installs,
both on Ubuntu and Debian, but the current patch does not break
anything as far as I can tell, so I'm signing off.
I tested with two libraries in the same search domain, with each
library owning a different book by the same author. Searching for
the author in
- all libraries,
- individual libraries and
- the search domain that contains both libraries
all return the expected results.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
I couldn't reproduce the problem, but didn't find any regressions.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test plan:
1 - turn on EnableOpacSearchHistory
2 - launch some searches at the opac
3 - go to your search history
4 - there is no history!
5 - apply this patch
6 - retry steps 1 to 3
7 - your history search is available!
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This does fix the bug, but does undo the change to make the cookie
utf-8 safe, however I think that change was done in the wrong way so
I am happy to sign this off
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Wondering if the comment line should be deleted now too.
Patch fixes the problem.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
To test
Search in the OPAC both logged and logged out
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
When I turn off XSLT for the OPAC I can recreate the problem.
After applying the patch things work as expected for all
combinations of:
- Search results and detail view
- Logged in and not logged in
- XSLT and non-XSLT view
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, QA script and test plan.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This feature enables a particular library's items to be emphasized and moved
to the first position on the search results and details pages of the OPAC.
It is enabled by the sytem preference HighlightOwnItemsOnOPAC.
To choose which branches items are emphasized, use the system preference
HighlightOwnItemsOnOPACWhich. It has two modes.
If set to PatronBranch, the items emphasized will be those of the same
library as the patron's library. If no one is logged into the opac, no
items will be highlighted.
If set to OpacURLBranch, the library is chosen based on the Apache
environment variable BRANCHCODE.
For example, this could be added to the OPAC section of koha-httpd.conf:
SetEnv BRANCHCODE "CPL"
The point of this feature is to allow each library on a given Koha server
to have a specific subdomain for the opac where that library's items are
empasized. That was http://branch1.opac.mylibrary.org will emphasize the
items of branch1, while http://branch2.opac.mylibrary.org will emphasize
the items of branch2.
Signed-off-by: Melia Meggs <melia@bywatersolutions.com>
Signed-off-by: Nora Blake <nblake@masslibsystem.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch adds the ability to add groups to the library select
pulldown on the opac, if it is enabled.
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Go to Administration › Libraries and groups
4) Create a new group, or edit an existing one
5) Ensure the 'Show in search pulldown' checkbox is checked
6) Save the group
7) Enable OpacAddMastheadLibraryPulldown if it is not already enabled
8) Load the OPAC, try the group search from the libraries pulldown menu
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Yes! Now this works, and well.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Removed NoZebra vestiges. This comprises several code blocks that depend on the NoZebra syspref and NZ related functions/methods.
C4::Biblio->
GetNoZebraIndexes
_DelBiblioNoZebra
_AddBiblioNoZebra
C4::Search->
NZgetRecords
NZanalyse
NZoperatorAND
NZoperatorOR
NZoperatorNOT
NZorder
C4::Installer->
set_indexing_engine
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Koha was not previously escaping CGI input, which caused problems for
highlighting and is a security issue.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Thx for fixing this.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This problem happens because there isn't a operator "phr" in the values
of callnumber and standard number search. So many results aren't the
corrects ones.
Test plan:
- Apply the patch
- In the dropbox search menu of OPAC main page header, the callnum
should have only callnum
- In OPAC advanced search the callnumber and standard number options
shouldn't have "phr"
- In staff client advanced search the callnumber and standard number
options shouldn't have "phr"
- Change OPACNumbersPreferPhrase and IntranetNumbersPreferPhrase to "use"
- The options listed before should use now the operator "phr"
- This will resolve the problems with the searches of callnumbers and
standard numbers in OPAC and staff client (spaces problems, no
results, inconsistent results, etc...)
Sponsored-by: KEEP SOLUTIONS
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I don't know how to reproduce the searching problems described in the
bug, but I can confirm that the patch works correctly to enable/disable
the use of 'phr' in the searches described in the test plan.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
System preferences work as described, switching indexes in
OPAC and staff.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Adds the following enhanced content to the OPAC, all controlled by
separate sysprefs:
1) A "Readometer" which summarizes reviews on the OPAC detail page
2) A tab with snippets of critical reviews on the OPAC detail page
3) A computed rating on the results page
To test:
Find a book that is listed on IDreamBooks.com (you may have to make
sure that you have the first edition), and one that is not. Try
each of IDreamBooksReadometer, IDreamBooksReviews, and
IDreamBooksResults sysprefs, taking note of the content appearing (or
not) as appropriate.
Updated to add missing CSS to new theme.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
all tests pass.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Rebased to latest master 2012-12-31
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When search failed, this patch gets the keyword(s) and add them
to the string entered by the user to OPACNoResultFound
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter for getAllLanguages.
In Languages.pm, getAllLanguages function is modified :
- if no parameter is passed to the function, it returns english languages names
- if a $lang parameter conforming to RFC4646 syntax is passed :
-- the function returns languages names translated in $lang if possible
-- if a language name is not translated in $lang in database, the function returns english language name
To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl :
- If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name).
- If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name).
Signed-off-by: Marc Veron <veron@veron.ch>
Patch behaves as expected.
With Opac language set to French I got all languages with French language name.
With German (de-DE), I got only a few with German language names (and all other with English ones),
this was due to missing entries for de-DE in table language_descriptions.
This behaviour is consistent with the description above.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested language list in OPAC and staff advanced search is translated
properly after applying the patch. Checked that language switcher still
works like it should.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Fixed typo in POD.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
When working with hierarchical subject headings, it is sometimes helpful
to do a search for all records with a specific subject, plus
broader/narrower/related subjects. This patch adds a suggestion plugin for
these "exploded" subject searches to Koha. Note that this patch depends on
both bug 8211 AND bug 8209.
To test (NOTE: this test plan covers both 8211 and 8726):
1) Make sure you have a bunch of hierarchical subjects. I created
geographical subjects for "Arizona," "United States," and "Phoenix,"
and linked them together using 551s, and made sure I had a half
dozen records linking to each (but not all to all three).
2) Do a search for su-br:Arizona (or choose "Subject and broader terms"
on the advanced search screen with "more options" displayed), and
check that you get the records with the subject "Arizona" and the
records with the subject "United States"
3) Do a search for su-na:Arizona (or choose "Subject and narrower terms"
on the advanced search screen with "more options" displayed), and
check that you get the records with the subject "Arizona" and the
records with the subject "Phoenix"
4) Do a search for su-rl:Arizona (or choose "Subject and related terms"
on the advanced search screen with "more options" displayed), and
check that you get the records with the subject "Arizona," the
records with the subject "United States," and the records with the
subject "Phoenix"
5) Ensure that other searches still work (keyword, subject, ccl,
whatever)
6) Use "Did you mean?" page in admin section to enable ExplodedTerms
plugin
7) Do a keyword search on the OPAC, confirm that searching for exploded
terms is suggested.
8) Do a subject search on the OPAC, confirm that searching for exploded
terms is suggested.
9) Do a non-keyword, non-subject search on the OPAC, confirm that
searching for exploded terms is NOT suggested.
10) Disable ExplodedTerms plugin and enable AuthorityFile plugin.
11) Do search on OPAC, confirm suggestions are made from authority file.
12) Sign off
Signed-off-by: wajasu <matted-34813@mypacks.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Split into two patches. This patch includes only the functionality.
This patch enables the shelving location facet as an
alternative to the branches fact in two situations:
A) SingleBranchMode is enabled
B) There is only one branch in the branches table
Test Plan:
1) Catalog multiple items with different shelving locations.
2) Test enable by enabling SingleBranchMode
3) Test enable by deleting all but one branch
Based on initial patch by Ian Walls.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Tested cases 2) and 3) successfully in OPAC and staff client
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This change some code a bit strange, that generate strange effetcs.
Now we use $cgi->param to get the values.
Test: search at the opac and intranet using limit, etc.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
One of the ideas behind authority records is that users who search for
one term should have related terms (according to the authority file)
suggested to them. At the moment, Koha doesn't do that. Adding an
authority searching step to regular searches and displaying any
suggestions in a "Did you mean" bar at the top of the results would be
very useful.
This commit adds a Koha::SuggestionEngine class which is in charge of
getting suggestions from individual suggestion engine plugins, which
much be in the Koha::SuggestionEngine::Plugin::* namespace, and extend
Koha::SuggestionEngine::Base. Suggestions are loaded asynchronously
using AJAX, and a link to a page with suggestions is provided for users
with Javascript turned off.
The AuthorityFile suggestion engine plugin looks up the specified search
terms in the authority file and then suggests searches for records using
matching authorities.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Rebased 2 August 2012 and incorporated QA feedback
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test plan:
- Verified database update added system preference correctly,
pref defaults to OFF
- Verified search results and detail pages in OPAC and staff
still worked the same as before
* for no results
* with results
- Activated system preference and tested various searches
* Searches from simple search
* Searches from advanced search
* Search links in records
- Deactivated Javascript - verified fallback works correctly
Notes:
- Suggested terms can include autorities with no linked records.
- When combining more than one search option using advanced search
this results in "no suggestions" more often. Feature works best
from simple search.
Overall great feature making use of authorities in a user friendly way!
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Rebased on latest master 2012-09-10
Signed-off-by: wajasu <matted-34813@mypacks.net>
This enhancement extends the OpacSuppression feature with an optional IP address range within which results are _not_ suppressed.
To test
* turn on OpacSuppression (Administration->System preferences->Cataloging) and enter an IP address range in the OpacSuppressionByIPRange field.
* set at least one bibliographic record to suppress=1 (enter '1' in 942$n)
* fully reindex your data
* do an OPAC search that should bring up your suppressed record
* try with IP ranges that match your IP and ranges that don't
Signed-off-by: Marc Veron <veron@veron.ch>
Tested following the scenario above. Works as expected.
