Bug 11401: Add support for Norwegian national library card

This patch makes it possible to sync patron data between Koha and the
Norwegian national patron database, in both directions.

In order to use this, the following information is necessary:
- a username/password from the Norwegian national database of libraries
  ("Base Bibliotek"), available to all Norwegian libraries
- a special key in order to decrypt and encrypt PIN-codes/passwords,
  which is only available to Norwegian library system vendors
- a norwegian library vendor username/password

See http://www.lanekortet.no/ for more information (in Norwegian).

While this is of course an implementation of a specific synchronization scheme
for borrower data, attempts have been made to prepare the ground for other sync
schemes that might be implemented later. Especially the structure of the new
borrower_sync table might be reviewed with an eye to how it might fit other
schemes.

To test:

Since the password and cryptographic key needed to use this functionality
is only available to Norwegian library system vendors, only regression testing
can be done on the submitted code. Suggested things to check:

- Apply the patch and make sure the database update is done. This should add
  the new "borrower_sync" table and five new systmpreferences under the
  "Patrons" > "Norwegian patron database" category:
  - NorwegianPatronDBEnable
  - NorwegianPatronDBEndpoint
  - NorwegianPatronDBUsername
  - NorwegianPatronDBPassword
  - NorwegianPatronDBSearchNLAfterLocalHit
- Check that patrons can be created, edited and deleted as usual, when
  NorwegianPatronDBEnable is set to "Disable"
- Check that the new tests in t/NorwegianPatronDB.pm run ok, e.g. on a
  gitified setup:
  $ sudo koha-shell -c "PERL5LIB=/path/to/kohaclone prove -v t/NorwegianPatronDB.t" instancename
- Check that all the other tests still run ok
- Check that the POD in the new files itroduced by this patch looks ok:
  - Koha/NorwegianPatronDB.pm
  - members/nl-search.pl
  - misc/cronjobs/nl-sync-from-koha.pl
  - misc/cronjobs/nl-sync-to-koha.pl
  - t/NorwegianPatronDB.t

Sponsored-by: Oslo Public Library

Update 2014-09-18:
- Rebase on master
- Split out changes to Koha::Schema
- Incorporate new way of authenticating with NL

Update 2014-10-21:
- Rebase on master
- Use Module::Load to load Koha::NorwegianPatronDB in non-NL-specific
  scripts and modules
- Fix the version number of Digest::SHA
- Fix a missing semicolon in kohastructure.sql

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

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: QA followup - fix pod

The QA script was complaining about some dodgy POD in C4/Members.pm,
that was not introduced by bug 11401. This patch fixes the POD, to
keep the QA script happy.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: QA followup

1) Be more careful when checking the NorwegianPatronDBEnable syspref.

Before:
if ( C4::Context->preference('NorwegianPatronDBEnable') == 1 ) {

After:
if ( C4::Context->preference('NorwegianPatronDBEnable') && C4::Context->preference('NorwegianPatronDBEnable') == 1 ) {

This should avoid complaints if the syspref is not initialized.

2) Fix some empty =head2 POD sections

3) Fix some indentation in patrons.pref, to make xt/yaml_valid.t happy

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I couldn't find any regressions with adding, editing and deleting members.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: QA followup - Make the tests pass

The configs in koha-conf.xml needed to be mocked. There was also
a problem with how the NorwegianPatronDBEndpoint syspref was
getting checked in the .pm.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: DBRev 3.17.00.055

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: DBIx updates

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: dependency updates

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13226: 9999-12-31 should not considered as a valid date

DateTime::Format::DateParse (called in Koha::DateUtils::dt_from_string)
does not manage to parse 9999-12-31 if a time zone is given.

my $date = DateTime->new(year => 9999, month => 12, day => 31);
 => OK

DateTime::Format::DateParse->parse_datetime( '9999-12-31' );
 => OK

DateTime::Format::DateParse->parse_datetime( '9999-12-31',
 'America/Los_Angeles' );
 => KO (~20sec on my laptop)

It should not be considered as a valid date when the letter is parsed.

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

Note that to reproduce the problem you much be checking in items from an
account which has been restricted indefinitely (either manually or by
the overdues process). With this patch such checkins go from taking
around 50 seconds (in my test system) to around 7 to 10 seconds.

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

Good catch! Works as described, no problems found.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13220 - Shipment date not saved when creating an invoice which has a duplicated number

When creating an invoice which has a duplicated number, if the user chooses to 'Create new invoice anyway', previously entered shipment date (todays date by default) is not being saved, because the date value is passed to the script in the wrong format (acqui/parcels.pl expects shipmentdate parameter to be in the system-configured date format, but what it's getting in such cases is ISO-formatted date instead). As a consequence (when receiving orders from invoice whith empty shipment date) 'datereceived' field in order records are also not being populated. Here and there, Koha is using datereceived field to establish if the order was received or not received, so such not-quite-complete orders:

- can be cancelled from the basket (even when they are de facto already received),
- it's not possible to cancel receipt of those orders from the invoice (because Koha is considering them as not yet received).

To reproduce:

1) Make sure you have some system date format configured in your test environment which is different from ISO format (e.g., DD/MM/YYYY) and the AcqWarnOnDuplicateInvoice syspref is enabled
2) Create some invoice with e.g. '11111' number,
3) Create another invoice with the same number (using 'Create new invoice anyway' button)
4) Try to create yet another invoice with the same number; observe that already existing invoice created in step 3) does have empty shipment date.
5) Optional: create some orders and receive them from the invoice with empty shipment date; observe that such orders are not being treated as received in all places (e.g. it's not possible to cancel receipts of such orders, and the message displayed is not in any way helpfull to determine why not).

To test:

1) Apply patch
2) Retest
3) Ensure that the issue is no longer reproductible, and that there are no apparent regressions of any kind.

Signed-off-by: simith <simith@inlibro.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tiny change fixing a bad bug. No problems found, passes tests and QA script.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13257: update_dbix_class_files.pl need a POD

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 10136: Remove outdated translation tool docs

Patch removes outdated translation tool documentation
from the misc/translator directory.

Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Removing these lines sounds like a good idea. I tested by
applying the patch and checking that the files in question
are gone.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13207: "Branch" on basket summary page should be "Library"

To test:
- Create or find an open basket/order in the acquisition module
- Check that "Branch" now reads "library"
- Set to "no library"
- No branches should be seen there.

Signed-off-by: jeremie.benarros <jeremie.benarros@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 7988: Make note on authorized values page less confusing

Nicole suggested a change of the note, that this patch is implementing:

NOTE: If you change an authorized value code, existing records
using it won't be updated. Changes to value descriptions will show
immediately.

To test:
- Go to administration > authorised values
- Check the note showing on the page
- Select a category from the pull down and edit an existing entry
- Check the note on this page is also correct

Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13082: fix to prevent adding of invalid records in marc file

Test:

1. Edit record, add 100.000 chars text to 500a

2. xml export produce the record,

3. mrc export do not produce the record, warning on log export.pl:
   Record length of 111000 is larger than the MARC spec allows (99999
   bytes). at /usr/share/perl5/MARC/File/USMARC.pm line 314.  record
   (number 139489) is invalid and therefore not exported because its
   reopening generates warnings above at...

Signed-off-by: Frederic Demians <f.demians@tamil.fr>

I confirm that exporting biblio records larger than 10000 characters in
ISO2709 produces invalid files. After applying this patch, the culprit
record (too large, but also other inconsistencies preventing record
parsing with MARC::File::USMARC) is not exported anymore. A warning is
produced in Koha Apache log file. Warnings to the user on WUI would be
better, but it isn't the case yet, so it isn't a regression.

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

I agree that a visible warning/result message in the staff interface
would be nice, but this works as described.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>