This patch modifies 13 HTML templates and includes that have lines in them longer than 998 characters. Lines this long are known to break git.
I believe that none of these change behaviour at all, but I'm concerned about one of them. It adds whitespace (carraige returns) inside a <title> tag. I'm not certain that all browsers will deal with this OK.
No documentation changes necessary here.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
If a MARC bib is modified by this batch job,
do not duplicate the item tags embedded in
it (e.g., 952 for MARC21). When modifying
a bib record, any embedded item tags must
be removed before calling ModBiblio - perhaps
this should be moved to ModBiblio itself.
Also removed an error in the job's help text.
Signed-off-by: Joshua Ferraro <jmf@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.
C4::Reserves::_Findgroupreserves(), instead of
getting all requests for a bib, now gets only the
requests that are title-level (itemnumber is null)
or for that specific item. This prevents an item
from filling an item-level hold for a different item
attached to the same bib, which is the expected
behavior for item-level holds.
[LL Bug 22]
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Pagination was working for searching, but the "type" and batch_id
were not making it onto subsequent pages (i.e., the 2nd page of "B"
names). This corrects the problem with the base URL passed to
pagination_bar.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The section in KOHA_CONF was moved inside <config> and renamed
<ldapserver>. Perldoc updated to correspond. Tested with local
LDAP and existing test (t/db_dependent/Auth_with_ldap.t).
Patch can be applied with confidence based on comparison of 2 dumps:
perl -e 'use C4::Context; use Data::Dumper; my $context=C4::Context->new("./old_config.xml"); print Dumper ($context->{server}->{ldapserver}),"\n";'
and
perl -e 'use C4::Context; use Data::Dumper; my $context=C4::Context->new("./new_config.xml"); print Dumper (C4::Context->config("ldapserver")),"\n";'
These dumps reflect the way Auth_with_ldap accesses configuration info before and after.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
This resolves all remaining significant parts of the bug.
Note that this may have to be revisited for hourly or partial-day circ functionality
for 3.2.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
OPACItemHolds
OPACShelfBrowser
have been added to updatedatabase.
The xslt sysprefs have also been added with a note stating they
only work with MARC21.
Without this patch, on OPAC result page, depending whether book cover
image is available or not, biblio records and book cover are badly
verticaly aligned. The information is in the middle of the cell.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
During link_bibs_to_authorities.pl run, a bib was
observed that had both biblioitems.marc and biblioitems.marcxml
set to blank or NULL. Added check to verify that a
defined value is returned from GetMarcBiblio(); may follow
up with additional patches once it's determined how
the corrupt bib came to be loaded.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Prevent following crash when linking a bib heading to an
authority record if the bib heading has a subfield whose code
is ')' or any other regular expression metacharacter:
Unmatched ) in regex; marked by <-- HERE in m/) <-- HERE / at
/home/koha-pro/kohaclone/C4/Heading/MARC21.pm line 186.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
In any MARC record display in the OPAC or staff client
that displays the MARC tag numbers, the indicators are
now displayed as well, following the tag number. If an
indicator is a blank, it is displayed as '#'.
Add a function to C4::Koha, display_marc_indicators(), to
generate this display form of the indicators.
Refactoring note: the four scripts changed in this commit
have a lot of duplicate code that could be merged into
a MARC displayer class.
Documentation notes: screenshots of tagged MARC record
displays should be updated.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Instead of having one input field for both indicators
of a variable field, the bib and authority MARC editor
now has an input field for each indicator. This has
two main advantages:
* it is easier to tell what the indicator values are,
even when the first indicator is a space
* it is easier to set the first indicator to blank
and the second indicator to non-blank.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The find_values() function in authorities/authorities.pl
and authorities/detail.pl is not used; appears to be copied
from additem.pl.
No documentation changes.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
1. Non-ASCII characters in the 942$h (biblioitems.cn_class)
would cause an edit to fail and lead to a corrupt MARC record in
biblioitems.marc and biblioitems.marcxml. Fixed by
turning on Perl's UTF-8 flag for MARC tag parameters
processed by C4::Biblio::TransformHtmlToMarc
2. Do not add empty 006 and 007 fields if the corresponding
input fields are blank.
3. Make it possible to save '0' as a valid subfield
value.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
In OPAC, when cart is sent by email, the email contains an attachement:
an ISO2709 file with cart biblio records. Most users don't have a clue
what to do with this file.
This patch modifies opac-sendbasket.tmpl to clarify what the attachment is.
It also fix a bug in opac-sendbasket.pl which wasn't reading the template
section containing information about the basket:
Here is your cart, sent from the Koha Online Catalog... foo
It may be necessary to verify that template text is in 'valid' English...
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
If a search contains a digit, it is almost certainly an identifier, and should
not be stemmed. This is particularly relevant for ISBNs and ISSNs, which
can contain the letter "X" - for example, C4::Search::_build_stemmend_operand
would reduce "014100018X" to "x ", which for a MARC21 database would bring
up irrelevant results (e.g., "23 x 29 cm." from the 300$c).
With this patch, supplying a search term that contains one or more digits
followed by "X" will no longer retrieve irrelevant results. This applies
to catalogs using Zebra and query stemming.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
