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.
OPAC search RSS and ATOM feeds now have the correct
Content-type sent - "application/rss+xml" and "application/atom+xml",
respectively.
As part of this patch, added an optional fourth parameter
to C4::Output::output_html_with_http_headers to specify
the content type. If that parameter is now supplied, or if
the value of the parameter does not contain at least a "/",
the default type of "text/html" is returned.
No documentation changes.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Fix several validation errors in RSS and Atom feeds
generated from the OPAC:
- add missing guid to RSS elements
- add missing feed ID and element ID to Atom elements
- reflect OPACBaseURL changes
- fix atom:link self links
- add HTML escaping to fields comming from bib record
- set default timestamp for Atom updated elements
Issues identified but not solved in this patch:
- setting Atom updated element for each bib (presumably
from biblio.timestamp)
- possible problems performing paging of Atom feed
Based on successful validation of feeds by feedvalidatory.org,
it is expected that feeds should now work in IE7 and IE6.
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>
in syspref it appears as "OFF", but in opac-search it's considered as true.
Changing the test to be sure syspref & opac-search consider the same thing
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
kados should commit something better, this is a quick hack.
if I send it mistakenly chris/kados, pls don't validate
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
This reverts commit 38884abf65.
This commit results in failed searches all over the place, I'm reverting
the revert :-)
Conflicts:
koha-tmpl/intranet-tmpl/prog/fr/includes/circ-search-autocompl.inc
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The patch default search on kw-wrdl is bugguy, as there ca be 2 idx (maybe an API limit,not sure)
So i've reverted it and added kw,wrdl on every place there is a query (the search boxes)
QUESTION : isn't it possible to have a single query for catalogue, that is TMPL_INCLUDE'd ?
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
without this, the search is done on kw, and truncation is not possible.
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Those subs were no more useful, the template didn't use them.
No hardcoding strings in .pl & .pm pls, we can't translate them.
Signed-off-by: Chris Cormack <crc@liblime.com>
