Bug 13253 - Unnecessary white space above checkouts table in circulation

On the new checkouts page there is some padding above the checkouts,
relatives' checkouts, and holds tables caused by extra markup in the
table's sDom configuration (http://legacy.datatables.net/ref#sDom):

<'row-fluid'<'span6'><'span6'>r>t<'row-fluid'>t

This creates several empty <div>s which don't serve any purpose. This
patch simplifies it to:

rt

To test, apply the patch, clear your browser cache, and check out to a
patron who has items checked out, holds on their account, and child
records attached which also have checkouts.

The padding above the table of checkouts, the table of relatives'
checkouts, and the table of holds should match that on the sides.

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Checked per plan on both Check Out and Details pages, spacing appears correct.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 6681: introduce XSLT scripts to remove items and links

This patch adds the following sample files:

- Del952.xsl
- Del995.xsl
- Del9LinksExcept952.xsl
- Del9LinksExcept995.xsl

Thay can be used on the new SRU/Z39.50 XSLT processing feature. At the same
time they can be used to solve this bug.

To test:
- Have an SRU/Z39.50 target configured
- Have a search that returns at least a record with the following
  properties:
  * It contains $9 links
  * It contains items (952 or 995 fields in MARC21/NORMARC and UNIMARC respectively).

MARC21/NORMARC test:
- Do a Z39.50/SRU cataloguing search that retrieves the desired record
- Verify it includes $9 and 952 field(s) by clicking on the MARC link
- Edit your Z39.50 target and add Del952.xsl to the "XSLT File(s) for transforming results:" field
- Re-run the search
=> SUCCESS: the MARC view of the imported record doesn't contain the 952 field
- Edit your Z39.50 target and add Del9LinksExcept952.xsl to the "XSLT File(s) for transforming results:" field
- Re-run the search
=> SUCCESS: the MARC view contains the 952 field (including the $9 subfield), and
            all other $9 subfields have been removed
- Edit your Z39.50 target and add
  Del952.xsl, Del9LinksExcept952.xsl
  to the "XSLT File(s) for transforming results:" field (both, comma separated)
- Re-run the search
=> SUCCESS: the MARC view doesn't contain $9 subfields nor items.

- Repeat for UNIMARC, replacing 952 for 995.
- Sign off :-D

Regards
Tomas

Sponsored-by: Universidad Nacional de Cordoba

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested under MARC21. Works fine. (Additionally verified 995 with xsltproc.)
As noted on Bugzilla, we could still improve documentation but imo no need
to block these example transformations.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I can't resist to put my own signature on this patch, confirming it works as
described with z39.50 Unimarc targets.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 6681: (qa followup) document the existence of the sample files

As requestedby people testing the patch, I add references to the new
xslt files on the Z39.50/SRU servers help.

Example usages are also provided.

Test:
- Apply the patch
- Go to the help page on the 'Z39.50/SRU Servers' page
=> SUCCESS: Notice there's a section documenting XSLT file(s) usage
            and provides some examples that cover the introduced files.
- Sign off

Thanks
Tomas

Sponsored-by: Universidad Nacional de Cordoba

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
  Help page does shed some light to the XSLT usage. Enough to my taste.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13232: Search patrons by a first letter should not redirect to a patron detail page

Bug 12833 allows to find a patron with his cardnumber.
But this won't never append if the firstletter parameter is given.

Actually the firstletter param is the only one to take into account if
it exists.

Test plan:
Search patrons by a first letter and verify that the feature is back.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

To reproduce the problem you need at least one borrower with a blank
cardnumber

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
works as descrobed, no problems found.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12779: Capitalization on add/edit subscription form

To test:
- Add or edit a new or existing subscription in the serials
  module

Patch changes "biblio" to "record" and fixes capitalization:
Search for record | Create record

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 13075: Silence warnings and improve Charset testing.

Calls to C4/Charset.pm's NormalizeString function with an
undefined string were triggering warnings when running:
  prove -v t/db_dependent/Holds.t

Sadly, t/Charset.t was also lacking calls to NormalizeString.

TEST PLAN
---------
1) prove -v t/db_dependent/Holds.t
   -- This should generate the uninitialized string warnings.
      Make sure CPL and MPL are in your branches to save
      yourself from headaches due to expected data.
2) cat t/Charset.t
   -- note there are no function calls to NormalizeString.
      You can see other shortfalls in the tests beyond
      NormalizeString with: grep ^sub C4/Charset.pm
3) prove -v t/Charset.t
4) Apply patch
5) prove -v t/Charset.t
   -- Run as before with more tests.
6) cat t/Charset.t
   -- note there are now function calls to NormalizeString.
7) prove -v t/db_dependent/Holds.t
   -- Nice and clean run! :)
8) koha-qa.pl -v 2 -c 1
   -- all should be Ok.

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

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13075: (followup) remove remaining warnings

There's no point creating a MARC record with undef subfields
for testing holds. This patch avoids that so no warnings are shown.

To test:
- Run
  $ prove t/db_dependent/Holds.t
=> FAIL: verify several warnings show
- Apply the patch
- Re-run
=> SUCCESS: no warnings showed.
- Sign off :-D

Regards

NOTE: Not noticable under Ubuntu 12.04 LTS, but verifiable under
      Debian Wheezy.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
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>