Bug 11579: Show ordernumber in basket.pl tables

Test plan:
Verify the ordernumber is correctly displayed on the basket page
(acqui/basket.pl?basketno=X)

Signed-off-by: silvere <silvere.hanguehard@enc.sorbonne.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed a tiny typo in the HTML: </th> > </td>.
Passes all tests and QA script.
Tested that the ordernumber is now displayed and table sorting
works for the smaller and more detailed table.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11439: (follow-up) adjust for change in list returned by OCLC XISBN

The set of related ISBNs for the first Harry Potter book returned
by OCLC's XISBN service has changed recently, so this patch adjusts
the test to match.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9823: Refactor return from GetReservesFromBiblionumber

The return from GetReservesFromBiblionumber contains an unnecessary
extra variable. In scalar context an array returns its element count.
Maintaining a separate count can lead to unforeseen bugs
and imposes ugly constructions on the subroutine's users.

Remove the useless count variable from the return

This patch also changes the parameters: now the routine takes a hashref.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Placed biblio holds, future holds and item holds. Works as expected.
Tested Holds.t and Reserves.t. Pass.
Tested /cgi-bin/koha/ilsdi.pl?service=GetRecords&id=999 with two holds on
one item. Fine.
C4/SIP/ILS/Item.pm: Looked for "whatever" and "arrayref" and could not find
them anymore. Looks good.
Handled a few unneeded calls in QA follow-up.
Left only one point to-do for serials/routing-preview.pl. See Bugzilla.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9823: QA follow-up for GetReservesFromBiblionumber calls

The template params holds and holdcount are not used in the ISBD template.
Removed the associated code from catalogue/ISBDdetail.pl.
Same applies for catalogue/MARCdetail.pl and labeledMARCdetail.pl.
Same applies also for catalogue/imageviewer.pl.
Same applies also for catalogue/moredetail.pl.

In catalogue detail.tt only the number of holds is used. Removed the code
that passed the holds array to the template.

For consistency opac-detail should also incorporate future holds into its
holds count; added the all_dates parameter for that reason.

The Reserves module is no longer needed in moredetail. Removed it. Checked
the other scripts also.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9823: (follow-up) improve POD for C4::Reserves::GetReservesFromBiblionumber

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11616: remove jQuery tablesorter plugin

DataTables has replaced the tablesorter plugin for client-side sorting
of tables in Koha.  There is no table using this plugin, so this patch
removes it and remaining references to it.

REVISED TEST PLAN
-----------------
1) Apply the patch
2) Home -> Koha administration -> Authorized values
3) Change the 'Show category:' drop down value, and play with
    the sorting of columns.
   -- should sort as expected.
4) Search the catalogue -> look for a biblio with high circulation
5) Click one of the name links.
6) Click the Items tab on the left.
7) Scroll down and click the (View item's checkout history)
    link in the History area.
   -- There was no sorting prior to the patch, so afterwards
      it should display the same.
8) git grep -i tablesorter
   -- Only a reference in staff-global.css and release texts.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11616: (follow-up) remove tablesorter CSS

This patch removes CSS rules that applied only to use of the
jQuery tablesorter plugin, which is now gone.

To test:

[1] Verify that git grep -l headerSort does not turn up
    any results.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11534: fix bug that made it impossible to remove instructors from a course

In some cases clicking the "remove" link to remove a course instructor
when editing a course reserves course doesn't work. I suspect this is
caused by leading zeroes in the card number. This patch refactors the
relevant function to fix the problem and to remove inline JavaScript
from generated markup.

Other changes:

- Make the "Remove" text translatable
- Re-order the first name and last name when added by JavaScript to
match the template's "surname, firstname" order.

To test:

1. If necessary, create or modify a patron to have a card number
   with leading zeroes.
2. Go to Course reserves and add or edit a course.
3. If you are editing a course and there are existing instructors, click
   the "remove" link. Nothing will happen.
4. Perform a patron search and choose one of the results. The name
   should be added to the list of instructors in the format "surname,
   firstname."
5. Click the "remove" link next to the patron name which was just added.
   Nothing will happen.
6. Apply the patch and repeat step 4. The "remove" link should work.
7. Add an instructor and save the course reserve. Repeat steps 2 and 3.
   The "remove" link should now work.

To test the translation fix, after applying the patch run "translate
update [language code]" and confirm that the "Remove" string is listed
in the updated po file for course_reserves/course.tt.

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>
Bug 11495: Make "Select titles to: " translatable

Fixes translation of "Select titles to: " on the Bootstrap
OPAC result page.

Test plan:
- Update one of the po files running:
  perl translate update <langcode>
- Verify that "Select titles to: " is only listed once for
  search-results.tt
Apply patch
- Verify addings titles to lists and cart from the result list
  still works as expected
- Rerun the po file update
- Verify the string is now listed twice for search-results.tt

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11488: make string "Are you sure you want to write off ..." translatable

Test plan:
- ./translate update LANG
- translate the string into your po file
- ./translate install LANG
- Verify the string is translated.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11268: increase size of biblioitems.url

The URL field in biblioitems is defined as a varchar(255) which is large
enough for most URLs but not all. This patch converts it to a
TEXT field to make sure it is capable of storing all valid URLs.

Test Plan:
1) Attempt to a URL that is greater than 255 chacters long in a record
   (856$u in MARC21)
2) Save the record, note the url gets truncated
3) Apply this patch
4) Repeat step 1
5) Note the entire url is saved

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11268: DBRev 3.15.00.016

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11268: (follow-up) update DBIC schema classes

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11513: fix log warning noise in patron category editor

Just going to the patron categories page triggered errors.
Running through all the plain options also triggered other
warnings. This fix silences them.

Discovered tabs I had not corrected by running qa test tool.

Some errors which I could not trigger were also fixed, such
as line 248 shown by Merllissia Manueli.

TEST PLAN
---------
 1) Log in to staff client
 2) Click 'Administration'
 3) Click 'Patron categories'
 4) Click '+ New category'
 5) Enter a dummy category and click 'Save'
 6) Click 'Edit' for the dummy category.
 7) Change a value and click 'Save'
 8) Click 'Delete' for the dummy category.
 9) Confirm to delete.
10) Review error log, several new warnings
11) Apply patch
12) Run the koha qa test tool.
13) Click 'Home'
14) Click 'Administration'
15) Click 'Patron categories'
16) Click '+ New category'
17) Enter a dummy category and click 'Save'
18) Click 'Edit' for the dummy category.
19) Change a value and click 'Save'
20) Click 'Delete' for the dummy category.
21) Confirm to delete.
22) Review error log, no new warnings

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

Followed test plan, saw no errors in the log after applying the patch.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested various dates and enrollment periods with different settings of
dateformat pref. Works as advertised. No warnings.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11513: (follow-up) format enrollment end date consistently

The previous patch added use of the KohaDates TT plugin, so this
patch makes sure that it gets used to format the display of all
occurrences of the enrollment end date.

To test:

[1] Create a patron category with a fixed end date.
[2] Bring up the list of all categories and verify that the date
    is displayed based on the dateformat value.
[3] Delete the category, and verify that the confirmation dialog
    formats the date correctly.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10811 - Add a 999$c record matching rule to the MARC21 defaults

This patch adds a default record matching rule for biblionumber
using the 999$c and the Local-Number index.

This is part of the optional marc21 SQL, as well as in the
updatabase.pl script.

TEST PLAN
---------
 1) Apply the SQL for adding the KohaBiblio matching rule.
 2) Run updatedatabase.pl
 3) Export some MARC bibliographic records from Koha
 4) Import those same MARC bibliographic records using the
     "KohaBiblio" record matching rule.
 5) The incoming records should match perfectly
 6) Check the mysql tables (marc_matchers, matchpoints,
      matcher_matchpoints, matchpoint_components,
      matchpoint_component_norms) to make sure the values were
     inserted as expected.

Optional: install a new Koha MARC21 database from scratch and
ensure that the sample matching rules are loaded.  Add at
least one bib record, and try steps 1-6.

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>

Dropped the database update from the original patch, as the matching
rules are not at present mandatory during installation.
Bug 10811: (follow-up) use "local-number" rather than "Local-Number"

At present, the QueryParser search mode expects that search field names
and aliases are case-sensitive.  This may change (see bug 11353), but
for now, this patch ensures that the local-number searches used by
the KohaBiblio rule will work regardless of the value of the
UseQueryParser system preference.

To test:

[1] Use the KohaBiblio 999$c matching rule with UseQueryParser both
    on and off.  Verify that matching by biblionumber works correctly.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11491: add option to supply field names in reports web service output

The staff and public catalog reports web services (/svc/report) return
JSON output, in particular an array contain an array for each row
of the report output.

This patch adds a URL parameter, annotated, which when supplied and
set to a value that evaluates to Perl true, will cause the output
to be emited as a JSON array of hashes, where each hash represents
a row of report output and the hash keys are the column names
or labels set in the report definition.

This patch also moves code around to make diffs between svc/report and
opac/svc/report smaller.

The suggestion to return an array of hashes was made by Chris Cormack.

TEST PLAN
---------
 1) Log into staff client
 2) Reports
 3) Used save reports
 4) Click the Action button on any report
     WITHOUT PARAMETERS.
    -- with parameters blows up in master and this.
 5) Click Edit
 6) Make the report public
 7) Update the SQL
 8) Note the ID number of the report
 9) Note the ID number of a non-public report
10) Make up a crazy ID number for a non-existant report
11) In a new tab (with the appropriate edits)
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 8
    -- JSON data has arrays of field values.
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 8&annotated=1
    -- JSON data has arrays of field values.
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 9
    -- Software error: Sorry this report is not public
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 9&annotated=1
    -- Software error: Sorry this report is not public
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 10
    -- Software error: Sorry this report is not public
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 10&annotated=1
    -- Software error: Sorry this report is not public
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 8
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 8&annotated=1
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 9
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 9&annotated=1
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 10
    -- Software error: hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at /usr/share/perl5/JSON.pm line 154.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 10&annotated=1
    -- Software error: hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at /usr/share/perl5/JSON.pm line 154.

12) Apply the patch
13) ~/qa-test-tools/koha-qa.pl -v 2 -c 2
    -- There should be no problems. All OK.

14) In a new tab (with the appropriate edits)
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 8
    -- JSON data has arrays of field values.
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 8&annotated=1
    -- JSON data has arrays of hashes with field names as keys
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 9
    -- Software error: Sorry this report is not public
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 9&annotated=1
    -- Software error: Sorry this report is not public
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 10
    -- Software error: There is no such report.
     https://OPAC/cgi-bin/koha/svc/report?id=# from step 10&annotated=1
    -- Software error: There is no such report.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 8
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 8&annotated=1
    -- JSON data has arrays of hashes with field names as keys
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 9
    -- JSON data has arrays of field values.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 9&annotated=1
    -- JSON data has arrays of hashes with field names as keys
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 10
    -- Software error: There is no such report.
     https://STAFF/cgi-bin/koha/svc/report?id=# from step 10&annotated=1
    -- Software error: There is no such report.

Signed-off-by: Holger Meißner <h.meissner.82@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11491: (QA follow-up) updated license and use Modern::Perl

Replaced License text with latest one from
    http://wiki.koha-community.org/wiki/Coding_Guidelines#Licence
and tweaked copyright lines accordingly.

Also changed use strict and use warnings into use Modern::Perl
as per PERL2 from the coding guidelines.

TEST PLAN
---------
1) less ~/kohaclone/opac/svc/report
   - The license does not reflect the current license
   - This will have use strict and use warnings
2) Apply patch
   - The license should be corrected
3) It should still run
     https://.../cgi-bin/koha/svc/report?id=##
     https://.../cgi-bin/koha/svc/report?id=##&annotated=blah
   Where ## reflects a public report available (for OPAC).

Signed-off-by: Holger Meißner <h.meissner.82@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11655: koha-translate --list no longer shows 'en'

'en' is not a translation and it doesn't make any sense to return it as
part of the installed translations or the available ones.

It becomes relevant to remove it as users upgrading their installed
translations end up grepping the output to remove 'en' like in:

for lang in $(koha-translate --list | grep -v -x -e 'en') ; do
  koha-translate --update $lang
done

instead of simply issuing the koha-translate --list command.

To test:
- Run
  ./koha-translate --list
  ./koha-translate --list --available
=> It shouldn't return 'en' in the result list.

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>