Bug 11290: fix display of patron home page for certain translations

To test
1) In a fresh Koha, generate translation into XX
2) Select XX for the staff interface (i.e. enable it, and choose it)
3) Go to the Patrons page
4) Everything looks fine
5) In the admin page, create a patron category with any non-ASCII
   character.
6) Go back to the Patrons page, everything is broken
7) Apply patch
8) regenerate translation
9) Go back to the Patrons page, everything looks fine
10) Switch to english it still looks fine

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Tried with ru-RU and fixes the problem.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Problem is also visible on untranslated templates changing
one of the sample category descriptions to include diacritics.

[RM note: I wasn't able to reproduce this on an unstranslated
 template -- I tried using Arabic, Cyrllic, and Spanish characters]

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
bug_10781: Remove C4::ILSDI::Utility

This patch removes C4::ILSDI::Utility on the basis
that one of its routines (BorrowerExists) was not used
and that the other routine can be (and is) moved to
C4/ILSDI/Services.pm.

Test:
This should be a noop. Regression testing required:
/cgi-bin/koha/ilsdi.pl functioanality, in particuler:
GetAvailability - ?service=Describe&verb=GetAvailability
AuthenticatePatron - ?service=Describe&verb=AuthenticatePatron

ILS-DI syspref must be turned on

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10688: Don't prefix index inappropriately

If you select an index in the search dropdown and then enter in a QP
query starting with the field, Koha will prepend the index you do not
want to use at the beginning of the search, resulting in a search that
probably does not match what you were hoping for.

To test:
1) Select an index in the search dropdown in the OPAC. Author is fine.
2) Enter a search term using manually entered indexes. For example:
    ti:cat in the hat
3) Note that the search fails.
4) Apply patch.
5) Repeat steps 1 and 2.
6) Note that the search succeeds.
7) Sign off.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 8683: ensure clear button clears all item fields on order form

The clear js function parses input text, but input filled to a plugin
does not contain the type attribute.

Test plan:
- fill the barcode field to the barcode plugin
- go on the new order page
- verify the barcode plugin works as before
- verify the clear link clears the barcode field and all others fields.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>

Works as expected, passes all tests and QA script.
Template change only.
Barcode and date acquired are now also cleared with the
'clear' link.

But: it only works when you enter a barcode manually currently,
because the AutoBarcode functionality is broken on master (bug 11273).

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10661: format mandatory item fields the same on all forms

Mandatory item fields are not indicated the same way in all places. This
patch corrects two places where required fields were shown in bold
rather than using the standard "required" class: When adding an order
from a staged file and when adding an item for a new issue of a serial.

This patch also normalizes the text input size on item entry forms: In
some places it was 50, others 67. I have changed the latter to 50.

Unrelated changes: Added $KohaDates formatting of date and time and
corrected capitalization on a heading on the add order from staged file
page.

It would be nice to be able to use the same method for displaying the
item form as we use on neworderentry.tt -- pulling in the form from a
separate include. However that system is designed for handling multiple
items and would need to be adapted for these cases.

To test, you must have a staged file from which to add an order. Open an
existing basket or create a new one and choose to add an order "From a
staged file." Choose a staged file from which to order. The item entry
form under the "Import all" heading should show required fields in red.

To test in serials: Begin the process for receiving an item from an
existing subscription. On the serials-edit page, find the "Click to add
item" links and click to open the item edit forms. There should be one
under the numbered issue and the supplemental issue forms. In both cases
the item edit screen should show the mandatory item fields in red.

Confirm that the cataloging add item form looks correct and works
correctly.

Revision: Left out the "required" note which should appear after each
required field.

Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10808: make authority search form retain drop-down selections

When cataloging a field defined with a thesaurus, an authority search
popup is displayed with a search from. Once operators, values and sort
selected in this form the search can be performed. The bug is that the
values entered are kept but not the selected operators and sort.

The same bug was existing in authorities module, solved by Bug 8692.

This patch corrects the bug.

Also uses in 'sort by' options the same text as search in authorities
module : Heading A-Z (default), Heading Z-A, None.

Also removes duplicated code in auth_finder.pl :
    value_mainstr => $query->param('value_mainstr') || "", ...

Test plan :
- Create a new biblio with a framework containing a field linked to a
  thesaurus. For example : 600
- Click on small icon of main entry. For example : 600$a
=> You get a search form with all operators to "contains" and sort by
   "Heading A-Z"
- Enter a value in each text box and perform search
=> You get a search form with values in text boxes and all operators
   to "contains"
- Select "starts with" in all operator comboboxes and perform search
=> You get a search form with all operators to "starts with"
- Select "is exactly" in all operator comboboxes and perform search
=> You get a search form with all operators to "is exactly"
- Select "Heading Z-A" in sort by and perform search
=> You get a search form with "Heading Z-A" in sort by
- Select "None" in sort by and perform search
=> You get a search form with "None" in sort by

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: With both patches applied no koha-qa errors

Test
1) Original behavior is whatever selection you do before patch,
search form returns to default options
2) After patch, selection remains

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass, further comments on second patch.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10808: (follow-up) reformat auth_finder.pl

Perltidy and some format changes.

Most important : call to get_template_and_user must be at begining
of script because it checks authentification.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes:
- Tested various searches, selections now remain after
  submitting the search form.
Regression testing:
- Clearing the authority from the record still works.
- Creating a new authority from the plugin page
  still works.
- Autocomplete of entries still works.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10605: fix encoding issue in basket email (OPAC)

There is an encoding issue on the received mail.
Here, we have to keep the encode_qp in order not to break links (= is a
special char for email https://en.wikipedia.org/wiki/MIME#Encoded-Word).

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10605: fix encoding issue on basket email (INTRANET)

Same fix for the staff interface.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Both patches tested with English and German, diacritics
now appear correctly if UTF-8 is selected as encoding.
Passes all tests and QA script.

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11032: Check a valid MARC::Record passed to Biblio

Intermittently problems in the calling environment
cause a C4::Biblio routine to be called with an undefined
MARC::Record object. This results in the process
dying and returning to the end user a low level
message such as 'cannot call method x on an undefined
object'.

For exported subroutines taking a MARC::Record object,
check that object is defined otherwise return a logical
return value and log a stack trace to the error log.
A couple of cases were checking but dying, this may have
unwelcome results in a persistent environment so croak has
been downgraded to carp

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>

Adds lots of checks for $record in various places, should
not affect behaviour.
Passed all tests and QA script, including new unit tests.
Tested adding and saving a new record.
Also tested detail and result pages without XSLT.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11112: Koha::Calendar needs some caching

Each time a Koha::Calendar object is created, its constructor retrieves
all holidays from the database and create a DateTime::Set object with
all holidays.

[RM note: I've observed that the time it takes DateTime::Set to be
 initialized with a set of dates increases faster than linearly with
 the number of dates.  I think this, more than just retrieving a bunch
 of holidays from the database, is what is most expensive.]

In one of our customer's DB, there are 11085 special_holidays and 598
repeatable_holidays. When a loan is returned, there are 3 calls to
Koha::Calendar->new.

This patch adds caching of the holiday list via package-level variables
as well as lazy fetching of the holidays. (RM note: this means that if
a persistance engine is in use, updates to the holiday list will not
be reflected during checkout.  I'm allowing this breakage for now on
the plan that bug 8089 will be fixed soon and we can switch to using
Koha::Cache).

Nytprof benchmarks (on a 3.8.x branch):
In DateTime::Set->from_datetimes:
3 times (5.49ms+4.90s) by Koha::Calendar::_init at line 80 of Koha/Calendar.pm, avg 1.63s/call
on a total of 7.67s (of 10.2s), executing 6353333 statements and 3031273 subroutine calls in 147 source files and 36 string evals.
for the circulation/return.pl page.

Comparing the access_log:

Without the patch:
checkout: time=2759838
checkin: time=1832751

Without the patch and with overdues:
checkout: time=1086727 + time=1144706
checkin: time=3928854 (x2)

With the patch and overdues:
checkout: time=1077839 + time=1060886
checkin: time=2420898

Test plan:
- checkout an item with a return date < today
- checkin the item and verify the suspension period is well calculated
  (depending on the holidays).
- prove t/db_dependent/Holidays.t
- t/Calendar.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11112: (follow-up) repair Koha::Calendar->add_holiday()

This patch ensures that the package-level cache is updated
when add_holiday() is used.  Note that except for the test
case added by this patch, there doesn't seem to be anything
that actually calls ->add_holiday(); it may be better to remove it.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11112: (follow-up) add FIXME

The caching introduced by the main patch is not ideal
as it won't work correctly if a persistance engine is used.

However, I have good reason to expect that bug 8089 will
be worked on (because I'm going to do it) so that Koha::Cache
can be used for this prior to the release of 3.16.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11009: Do not display circulation history of anonymous patron

When using an anonymous patron to anonymise issues history, this patron
may have a huge number of old issues. In this case, trying to display
the reading history of this patron will perform a huge SQL query.
It is not useful to have the reading history of this anonymous patron.

This patch adds an alert instead of old issues when displaying reading
records of anonymous patron.

Test plan :
- Set syspref AnonymousPatron to 0.
- Select a borrower with old issues. For example 123.
- Look at its reading records page : members/readingrec.pl
=> Old issues are displayed in a datatable
- Set syspref AnonymousPatron with this borrower number. For example 123.
- Look at its reading records page
=> Old issues are not displayed and an alert is displayed
- Using SQL query, remove old issues of this borrower :
    DELETE FROM old_issues WHERE borrowernumber=123.
- Look at its reading records page
=> A message is displayed

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

This works as advertised and seems like a reasonable thing to do. I
suspect that someone will object... Perhaps that person will implement a
solution which uses an AJAX DataTable.

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11009: (follow-up) tweak wording and remove potential log noise

This patch makes the message that is displayed when attempting to
view circ history for the anonymous patron more informative.  It
also removes a potential source of log noise if the AnonymousPatron
system preference happens to be set to a blank value.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>