Having the place multiple holds button at the top of the OPAC and staff search results has caused problems for some sites with tight holds policies; this syspref allows those sites to turn off the button.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
In Opac :
Print lists
Carts looks more like lists
Carts "More Details" And "Brief Display" toolbar looks more alike
In Admin :
Search results toolbar now have a "Add To" button for adding to a selected list with a confirmation pop-up, like in OPAC
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Stemming is now available for more languages
Adding also getDistinctValues which gets distinct values for a zebra index or for a Mysql field
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
If the advancedSearchTypes = CCODE, the code descriptions are not alphabetized, as opposed to itemtypes, which are alphabetized.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The intent of kohaspsuggest is very confused. It wanted to simultaneously
log every search query, and get spelling suggestions from a totally different
database_host:db_user:db_password:database. The implementation seems
never have really made it into 3.0, however, since the only trace of the
tables it wants to query are in misc/migration_tools/22_to_30/phrase_log.sql
The job misc/spellcheck_suggest/make_spellcheck_suggest.pl does not even
target the same remote DB as the syspref tells the search code to do. Instead, it hits the
local DB and, not finding the tables that have no way of existing in a 3.0
install, it CREATES its own tables spontaneously, using MyISAM storage, no less.
This script should be drastically overhauled, or more likely just removed.
Other fixes:
Commented out unconditional warn!
Also reduced bizarre whitespace amounts in catalogue/search.pl and
fixed warning as recommended by perl -wc:
Scalar value @newresults[0] better written as $newresults[0]
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Coding by Rick Welykochy <rick@praxis.com.au>
[1] Three new system preferences to enable particular
bib record views in the staff interface:
viewMARC
viewLabeledMARC
viewISBD
Implements enhancement 2642.
[2] New button in the regular and cataloging search results
pages in the staff interface to allow the operator to redo
the search against Z39.50 targets instead of the Koha database.
[3] Added copyright date and edition to cataloging and Z39.50 search results.
Implements enhancement 2640.
Feature sponsored by MassCat.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Per discussion I had with Henri, removing experimental
bulk editing from the staff search results code, as
feature is incomplete and can be dangerous if
one tries to use it on a large search result
set.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
there is some old 2.2 code for more complete labels-searching, thats been commented out
ive logged a 'bug' for this - 2777
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2777
this fix...
- enables the index-searching functionality
- adds date-ranges
- uses the numSearchResults syspref, not a hardcoded '20'
- rewrote old 2.2 page-num code, (didnt work for 3.x)
- some indent and whitepages tidys.
- unused 2.2 search-code removed.
Mason
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
seems that when itemtypeimagelocation returns undef, the hash is messed up.
put it at the end of the hash and everything is fine.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This adds a new function, getitemtypeimagelocation, that returns the image
unmodified for absolute urls and returns the proper intranet or opac path
otherwise. It also updates all of the relevant files to use that function.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The issue was that the index for itemtype is different depending
on whether you're using item-level or bib-level itemtypes. This
patch detects the system choice and sets the index properly
For documentation, please indicate that as part of profiling,
staff can refer to the AdvancedSearchTypes system preference to
choose where to draw the advanced search 'Types' from. Currently
this is implemented as a choice, between itemtypes and ccodes,
but it's been designed to work with any authorised value so long
as an index exists for searching by that authorised value.
By default, and if this syspref doesn't exist, it will pull from
itemtypes as before.
This patch is meant to guarantee that a bulkedit
does not try to edit an item tag embedded in a MARC
biblio without updating the items feature. It is
not a comprehensive fix of the bulkedit feature, which
currently does not appear to be functional and
needs some thought:
* The general search results is probably not the
best place to put this feature -- it should
probably be in tools.
* A bulk edit of something like items is desireable,
but needs to be designed so that it respects
business logic for circulation and acquisitions.
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Getting Search.pm air tight ... cleaned up some local variables
that were declared global
fix to asynchronous federated searching lost since dev_week, immediate
use is authority search
template fixes to item-level itemtypes and bib-level itemtypes
temp workaround to javascript problems preventing item edits
fix to installer
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Summary of Koha 3.0 date indexing for MARC21:
Index Expected format Notes
-----------------------------------------------------
date-entered-on-file [yymmdd] (008/0-5, indexed in word and sort indexes)
copydate [yyyy] (260$c, indexed in word and sort indexes)
acqdate [yyyy-mm-dd] (952$d, indexed in date,word,sort indexes)
pubdate [yyyy] (008/7-10, indexed in year,word,sort indexes)
Template Search Parameters Tested:
limit-yr (either yyyy or yyyy-yyyy) (added processing for ge le, structure attribute st-numeric, etc.)
yr pubdate (yyyy)
acqdate,st-date-normalized (yyyy-mm-dd)
Template Sort Parameters Tested:
pubdate_dsc
pubdate_asc
acqdate_dsc
acqdate_asc
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
parenthesis introduce a priority.
yr:XXXX-YYYY is now processed correctly.
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
