Preliminary (beta) release notes for 3.18

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

Translation updates for Koha 3.18.0-beta release

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

Update .mailmap file for release

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

Bug 12992: Fund planning should display actual values

The 'show_actual' variable is not correctly manage in the template.
This has certainly been introduced by the migration to TT.

Test plan:
1/ Go on a bugdet planning view (admin/aqplan.pl)
2/ Check the "Show actual/estimated values" checkbox on the left
(Filters box)
3/ Go
4/ Verify the actual values are now displayed (i.e. the columns contain
2 values).

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13195 - Regression: Circulation checkouts table no longer shows item type description

Another regression caused by Bug 11703: The list of checkouts on the
circulation and patron detail page shows item type codes instead of the
full description.

Test Plan:
1) View a patron's checkouts, note the Item type column displays the
   code rather than the description.
2) Apply this patch
3) Refresh the page, note the description is now displayed

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

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

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

Bug 13236 - Regression: Table of checkouts no longer preselects overdue items for rewewal

Before Bug 11703, overdue items in the list of a patrons checkouts had
the renewal checkbox preselected so that librarians could quickly renew
only those items which required it. This is not longer the case.

This patch corrects it. To test, apply the patch and clear your browser
cache. Check out to a patron who has overdues and confirm that the
overdue items have the "renew" checkbox preselected. Check that items
which are not overdue are not preselected.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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 13196 - "Always show checkouts immediately" cookie should persist across sessions

This patch modifies the way the checkouts script sets the "Always show
checkouts" cookie so that it is set with an explicit expiration date
(+365 days). This will allow the cookie to persist across browser
sesssions.

To test, apply the patch and clear your browser cookies to start with a
clean slate.

- Check out to a patron who has existing checkouts. Their checkouts
  should not load by default.
- Check the "Always show checkouts immediately" checkbox.
- Close your browser.
- Reopen your browser and check out to that patron again. Checkouts
  should now be displayed by default.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Works as described. I confirm that without this patch, the un-persistance of
"show checkouts" choice is very perturbing for librarians coming from previous
version of Koha.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, no problems found.

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

Bug 13168 - "Today's checkouts" sort improperly because issuedate lacks seconds.

TO REPLICATE:

Prepare a bunch of Items (6+) for checking out, or have a set of barcodes ready for copy-pasting.
Check-out those items quickly within one minute and observe that the sorting order is not always from the first checkout to the last.

This is because the issuedate doesn't have seconds defined.

AFTER THIS

The bunch of Items is sorted properly.

Tiny patch, works as expected. Passed QA script.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13254 - Delete record don't wait for confirmation

In some cases (eg. when Staf Client Search is active), when user choose
Edit->Delete record on record tool bar, browser don't wait for
confirmation and goes immediately to delete record.

To reproduce:
1. Search for some biblio records and choose one without items attached.
2. Note that there, must be "Return to search results" box on left side,
bug works in that case, when in normal view everything work fine.
3. Click Edit->Delete record, watch that confirmation box shows, but
don't wait for OK and runs immediately. If you are fast enough to
click OK, then you get error as below, because record was deleted
earlier.

To test:
1. Apply patch.
2. Follow reproduce steps.
3. Check if waits for confirmation in all cases.
4. Check if deletes record after confirm.

Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and that the patch fixes it.
Good catch!

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

Bug 10878: Correct Display856uAsImage pref description

Removes note about Display856uAsImage not working on
the OPAC result page.

To test:
- catalog a record with 856$u = URL to an image, $q = img
- turn on the system preference Display856uAsImage
- check that the pref description makes sense and is correct
  - the warning about the pref not working on result pages
    has been removed
- make sure your record has been reindexed by Zebra
- verifiy the image indeed displays on the result page
  in the bootstrap catalog.

Note: The height=100 doesn't work in the Boostrap catalog,
so the images display in their original size. Will file
a separate bug for this.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13258 - Clicking the "show checkouts" button should return focus to the barcode field

This patch udpates the checkouts JavaScript so that clicking the "show
checkouts" button or the "always show checkouts" checkbox returns focus
to the barcode field. This improves the checkout workflow by eliminating
a mouse click.

To test, apply the patch and clear your browser cache. Check out to a
patron and confirm that focus is returned to the barcode field after
clicking the "show checkouts" button and the "always show checkouts"
checkbox.

Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
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 12778 - Regression: Item lost status doesn't show in list of checkouts

When using the longoverdue script it's possible that items marked lost
remain on the patron account. I think it's important for staff to see
that some items are marked lost - currently the list of checkouts
doesn't show any sign of the lost status.

Test Plan:
1) Find a patron with a checked out lost item
2) Note the lost status is not displayed in the checkouts table
3) Apply this patch
4) Refresh the page, note the lost status now displays
5) Repeat this test plan for a damaged item

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Tested successfully with damaged and multiple lost values.

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 13122 - Patron holds table no longer display date item went in transit

In Koha 3.14 and earlier, an item on hold and in transit would display
the date the item was transferred. This is missing from the new ajax
holds table.

Test Plan:
1) Place an item on hold for delivery at a different library
2) Check the item in, confirm the hold and transfer
3) View the patron's holds tab on circulation.pl and/or moremember.pl
4) Note the item is show as in transit, but does not give the "since"
   date
5) Apply this patch
6) Note the in transit status now has a "since <date>"

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Small change, works as described.

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

Bug 13256 - Typographical error on item search template

Typo error found in the new template itemsearch.tt line 363 "_ matches
only a single charcter"

Test plan:
1) Go to url 'intranet-tmpl/prog/en/modules/catalogue/itemsearch.tt'
   line 363 and check the typo "_ matches only a single charcter" and
   change for _ matches only a single character
2) Apply the patch
3) Repeat step 1 and check if the typo is fixed

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13233 - Patron search by birth date tooltip broken

When the user selects a patron search by birth date a tooltip is
supposed to appear showing the date format requirement. Bug 9811 (Patron
search improvement) changed the ID on which the tooltip depended to
function. This patch corrects it.

To test, apply the patch and go to the Patrons home page in the staff
client. In the header search form select "Date of birth" from the
"search fields" dropdown. This should trigger a tooltip showing the
required date format.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I confirm the tooltip comeback with this patch.

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 13227: Display856uAsImage displays images in OPAC in original size

To test:
- catalog a record with 856$u = URL to an image, $q = img
- turn on the system preference Display856uAsImage
- make sure your record has been reindexed by Zebra
- verifiy the image indeed displays on the result and detail page
  in the bootstrap catalog.

The image shows in the original size, from the code it's meant
to display with a height of 100 px, but this won't work in bootstrap
as the height is set to auto with CSS.

Patch changes the XSLT to restore the former behaviour.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11401: (followup) make tests run on absent deps

The current code breaks if a dependency is missing. The evals are
rearranged so there's no error on missing dependency.

To reproduce:
- Have a dependency for t/NorwegianPatronDB.t removed
- Run
  $ prove t/NorwegianPatronDB.t
=> FAIL: You see an error similar to this (may vary depending on the lib you removed):

t/NorwegianPatronDB.t .. You tried to plan twice at t/NorwegianPatronDB.t line 37.

- Apply the patch
- Run
  $ prove t/NorwegianPatronDB.t
=> SUCCESS: Tests are skipped on missing lib

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

Bug 10473: (RM followup) small wording change

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

Bug 10473: Get rif of the placeholder

This placeholder is not really relevant here.

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

Bug 10473 - Max length should be 2 digit for adding multiple copies in add items page

As per the discussion, a prompt on a hard coded soft-limit is
far more acceptable as a solution.

TEST PLAN
---------
 0) Back up your DB. -- because a backup is always good!
 1) Log in to staff client
 2) Navigate to any biblio details
    (e.g. cgi-bin/koha/catalogue/detail.pl?biblionumber=#####)
 3) Click the 'Edit' dropdown button.
 4) Click 'Edit items'.
 5) Click 'Add multiple items'
 6) Enter a crazy high number (e.g. 999)
 7) Click 'Add'
    -- Koha just adds it! YIKES!
 8) Apply patch
 9) Repeat steps 5-7
10) Click 'Cancel'
    -- Koha does not add the items.
11) Repeat steps 5-7
12) Click 'Ok'
    -- Koha does add the items.
13) run koha QA test tools
14) Restore your DB.

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11413: Fix field_numbers

This fix is a global fix for the MarcModificationTemplate feature.
Some unit tests were missing and some behaviors were wrong.
For instance, if you tried to update a non existent field, the script
crashed.

The following line was completely stupid:
    if $from_field ne $to_subfield

The field_number equals 1 if the user wants to update the first field
and 0 for all fields.

The field_numbers (note the s) variable contains the field numbers to
update. This array is filled if a condition exists (field exists or
field equals).

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11413: Fix return for ModifyRecordWithTemplate

Make sure the ModifyRecordWithTemplate routine returns undef.

This patch also removes a warning if GetModificationTemplates is called
without parameter.

Verify
  prove t/db_dependent/MarcModificationTemplates.t
returns green.

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11413: Reflect the changes to the interface

Test plan:
- add/edit an action on the marc modification templates tools
- choose an action and define a condition
- define the source field as same as the condition field
- verify the All/1st dropdown list is changed to Every/1st

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11413: UT to show up the issue

These UT reflect this change:
- deletion of the field 245 if 245$a='Bad title'
- move of the 650 field to 651 if 650$9=499

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11413: Change the field number logic

This patch series is a bugfix for the Marc modification templates tool.

Bug description:
If you want to do an action (delete/update/move/...) on a multivalued
field and if a condition is defined on the same field, it is highly
probable the resulted record will not be what you expect.

For example:
Deleting All (or the first) fields 650 if 245$a="Bad title" works with
the current code.
BUT if you want to delete All (or the first) fields 650 with a condition
on 650$9=42, and if at least one field matches the condition :
- if you have selected all, all fields 650 will be deleted, even the
  ones who do not match the condition.
- if you have selected first, the first 650 field will be deleted, even
  if it does not match the condition.
The expected behavior is to delete the fields matching the
condition (and not all the 650 fields).

What this patch does:
This patch introduces 2 changes in the logic of Koha::SimpleMARC.
The first change is a change of the prototypes for the 2 routines
field_exists and field_equals. Now they return the "field number" of the
matching fields.
The second change is the type of the "n" parameter for all routines
using it in Koha::SimpleMARC. Before this patch, the "n" parameter was a
boolean in most cases. If 0, the action was done on all fields, if 1
on the first one only. Now it is possible to specify the "field numbers"
(so the array of field numbers which is returned by field_exists or
field_equals) for all routines which had the n parameter.

Test plan for the patch series:
Note: This test plan describes a specific example, feel free to create
your own one.
0/ Define a marc modification template with the following action:
  Delete field 245 if 245$9 = 42
1/ choose and export a record with several 245 fields.
For ex:
  245
    $a The art of computer programming
    $c Donald E. Knuth.
    $9 41
  245
    $a Bad title
    $c Bad author
    $9 42
2/ import it using the Stage MARC for import tool.
3/ verify the imported record does not contain any 245 field.
4/ apply all the patches from this bug report
5/ do again steps 2 and 3
6/ verify the imported record contains only one 245 field, the one with
245$9=41
7/ verify the unit tests passed:
  prove t/SimpleMARC.t
  prove t/db_dependent/MarcModificationTemplates.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13064 - Indexing problem with ICU on control characters

The ICU configuration files contains a rule to remove control characters :
  <transform rule="[:Control:] Any-Remove"/>
This rule is before tokenization.

The problem is that "[:Control:]" regex contains line feed, carriage return and tab. See http://www.regular-expressions.info/posixbrackets.html.
So when several lines are indexed, last word of line is joined with first line of next line. Thoses words are then not searchable.

For example :
  First line
  Second line
This will become "First lineSecond line", tokenized as "First", "lineSecond" and "line".

Test plan :
- Use ICU in Zebra configuration
- Choose an indexed field, like 300$a
- Create a new record
- Enter several lines in choosen field, like :
  First line
  Second line
- Index this record
=> Without patch the search on "Second" does not return the record
=> With patch the search on "Second" returns the record
- Same tests with tab and carriage return instead of line feed

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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>

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 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 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 13257: update_dbix_class_files.pl need a POD

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 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 11401: dependency updates

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

Bug 11401: DBIx updates

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: 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: 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 - 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: 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 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 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 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 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 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 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 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 11634 [QA Followup] - Make unit tests pass

* Allow on shelf holds needed to be enabled
* Added some error supression code for undefined string comparison

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

Bug 11319: [QA follow-up] Remove a warning from GetModificationTemplates

Removes this warning: Use of uninitialized value $template_id in string eq
at C4/MarcModificationTemplates.pm line 84.

GetModificationTemplates has no template_id if called from
marc_modification_templates.pl without operation (first click from
interface) and from tools/stage-marc-import.pl.

Slightly adjusted the POD lines accordingly.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: [QA follow-up] Add test message to MarcModificationTemplates.t

The last test (#74) did not print anything. It now does..

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: Template modifications

This patch add template modifications for the restrictions:
- the source field is always mandatory
- on move and copy, the source and destination subfield should be both
  filled or blank.
- on move and copy, the destination subfield should be filled.
- on update, the subfield value should be filled.

Test plan:
Verify you are not able to create/modify template actions according to
these restrictions.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: Add specific UT for nonexistent field/subfield

This patch only adds unit tests for the copy and move actions.
They test if the action does not create a field/subfield if the source
did not exist.

Also it adds a unit tests for the existing behavior (in order not to
lost it): we can use the '^' and the '$' character in regex for
substituing. For example: Copy 245$a to 245$a with the regex s/^/BEGIN /
This will add the string "BEGIN " at the beginning of the 245$a fields.

To test: prove t/SimpleMARC.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: Add the field management for Koha::SimpleMARC

Currently the Koha::SimpleMARC module call a "field" a "subfield".
And the way to manage field is not implemented for all routines.

This patch does not modify the API. The routine's names are kept. It
just creates 2 privates routines for each action (e.g. delete_field
will call _delete_field if the action affects field and _delete_subfield
if the action affects subfields).

Before this patch the move action was authorised by the interface but
caused an error if executed.

Note: I don't see the meaning for the add/update action if no subfield
is given. So the call without subfield raises an error.

Test plan:
- apply all patches
- create or modify an existent template
- try at least the correct behavior for the following actions:
  * delete subfield and field
  * add new subfield to an existing field
  * add new subfield to an nonexisting field
  * move a subfield
  * move an entire field
  * copy a subfield
  * copy an entire field
- import a biblio and use this template
- verify the imported biblio matches actions defined.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: Add UT for the fields management

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11319: Koha::SimpleMARC should take a hashref for parameters

In order to avoid a long list of parameters, it should be better to
pass all of them into a hashref.

This patch does not add or modify a behavior.

Test plan:
Verify the unit tests still pass
- prove t/SimpleMARC.t
- prove t/db_dependent/MarcModificationTemplates.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 11634: DBRev 3.17.00.054

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

Bug 11634 [QA Followup 3] - Found holds should be considered unavailable

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

Bug 11634 [QA Followup 2] - Implement check for IsAvailableForItemLevelRequest

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

Bug 11634 [QA Followup] - Unit Tests

These new unit tests will fail due to the fact that Koha::Database
uses a separate dbh handle than C4::Context->dbh

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

Bug 11634 - Allow renewal of item with unfilled holds if other available items can fill those holds

The current holds behavior in Koha allows a situation like this:
- Patron A has an item currently checked out.
- Patron B places a hold on the next available copy of that title.
- Then Patron A will not be able to renew his item, even if there are
  other available copies of that title that could potentially fill Patron
  B's hold.

Since this seems unfair to Patron A, we should allow renewal of items
even if there are unfilled holds, but those holds could all be filled
with currently available items.

Test Plan:
1) Apply this patch
2) Create a record with two items
3) Check out the item to a patron
4) Place a hold on the record
5) Note you cannot renew the item for the patron
6) Enable the new system preference AllowRenewalIfOtherItemsAvailable
7) Note you can now renew the item, as all the holds can be satisfied
   by available items.
8) Place a second hold on the record
9) Note you can no longer renew the item, as all the holds *cannot*
   be filled by currently available items

Signed-off-by: Holger Meissner <h.meissner.82@web.de>
Signed-off-by: Chris Rohde <crohde@roseville.ca.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13116 [QA Followup] - Remove tabs, use unless instead of if

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

Bug 13116 - Make it possible to propagate errors from C4::Reserves::CanItemBeReserved() to the web-templates.

This patch changes the way CanBookBeReserved() and CanItemBeReserved() return error
messages and how they are dealt with in the templates. This change makes it possible
to distinguish between different types of reservation failure.

Currently only two types of errors are handled, all the way to the user, from the CanItemBeReserved():
-ageRestricted
-tooManyReserves which translates to maxreserves

 #############
 - TEST PLAN -
 #############
((-- AGE RESTRICTION --))
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You get a notification, that placing a hold on ageRestricted material is
   forbidden. (previously you just got a notification about maximum amount of reserves reached)

((-- MAXIMUM RESERVES REACHED --))
0. Set the  maxreserves -syspref to 3 (or any low value)
STAFF CLIENT AND OPAC
1. Make a ton of reserves for one borrower.
2. Observe the notification about maximum reserves reached blocking your reservations.

((-- MULTIPLE HOLDS STAFF CLIENT --))
3. Observe the error notification "Cannot place hold on some items"

((-- MULTIPLE HOLDS OPAC --))
1. Make a search with many results, of which atleast one is age restricted to the current borrower.
2. Select few results and "Place hold" from to result summary header element.
       (Not individual results "Place hold")
3. Observe individual Biblios getting the "age restricted"-notification, where others can be
   reserved just fine.

Updated the unit tests to match the new method return values.
t/db_dependent/Holds.t & Reserves.t

Followed test plan. Works as expected and displays meaningful messages for the reason why placing a hold is not possible.

Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: (RM followup) typo in sysprefs.sql

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

Bug 10632 [Follow-up] Enable datatables for courses and course details in the OPAC

This follow-up adds some style improvements and corrects some errors in
the previous patch:

- The path to datatables.css has been corrected
- Unused CSS has been removed from datatables.css (particularly related
  to pagination controls, which are currently unused in the OPAC).
- Style has been added to datatables.css to make the table search form
  look better.
- The configuration of the course details table has been enhanced to
  include a title sort which ignores articles and date sorting according
  to the "title-string" method for date format agnostic sorting.
- Unrelated: A message <div> has been modified to have the correct style
  for the Bootstrap theme.

To test you should have multiple courses and at least one course with
multiple reserves. Clear your browser cache if necessary and view the
list of courses in the OPAC. All table sorting should work correctly, as
should the table search form.

View the details of a course which has multiple reserves. All sorting
should work correctly, including title sort excluding articles. Sorting
by date due should work correctly for any dateformat system preference
setting.

View the details of a course which has no reserves. You should see a "No
reserves" message box with a style consistent with similar messages in
the Bootstrap OPAC.

View other sorted tables in the OPAC to confirm that the CSS changes
have not negatively affected their appearance: opac-user.pl for
instance, or opac-detail.pl.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 10632 - Enable datatables for courses and course details in the OPAC

We should use datatables for the courses and course items tables. This
will make the tables sortable and searchable from the client side.

Test Plan:
1) Apply this patch
2) View the courses in the OPAC, try sorting and searching
3) View the course details for a course, try sorting and searching the items.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signing off, but have a follow-up to address some missing stuff.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 8218: qa followup

This patch
- rename _entity_clean as _clean_ampersand
- rename the script to sanitize_records.pl
- add a --fix-ampersand switch (the only one FOR NOW, enabled by
  default) so it is obvious what the script does.
- make POD and usage reflect this changes.

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

Bug 8218: Follow-up for some small typos

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 8218 : Add a maintenance script to sanitize biblio records

This patch adds:
- a new maintenance script batch_sanitize_records
- a new subroutine C4::Charset::SanitizeRecord
- new unit tests for the new subroutine

Test plan:
1/ prove t/db_dependent/Charset.t
2/ Create a record containing "&amp;amp;" (could be follow with as many
'amp;' as you want) in one of its fields and the same for the field
linked to biblioitems.url.
The url should not be sanitized, it may contain "&amp;".
3/ Launch the maintenance script with the -h parameter to see how to use
it.
4/ Launch the script using the different parameters:
 --filename=FILENAME
 --biblionumbers='XXX'
 --auto-search

The auto-search permits to sanitize all records containing "&amp;amp;" in
the marcxml field.

Use the verbose flag for testing.
Without the --confirm flag, nothing is done.

5/ Use the --confirm flag and verify in the biblioitems.marcxml field
that the record has been sanitized.

6/ Try the --reindex flag to reindex records which have been modified.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12258 [Template follow-up] Datatable in Patrons Account Fines

This follow-up corrects some of the QA issues affecting the other patch,
as well as changing the way the "filter" option is displayed:

- Added the use of the DataTables include file
- Removed redundant document.ready
- Fixed single quotes
- Fixed default sort (should be date descending to match the current
  functionality)
- Adding missing <tr>
- Converted filter button to a link

The last change is a judgement call, but the button in the DataTables
toolbar looked awkward and caused ugly wrapping at narrower viewport
sizes. I think a link is more keeping with the pattern established by
"select all / clear all" links.

To test, apply both patches and view the account page
(members/boraccount.pl) for a patron who has paid and unpaid fines (the
more the better).

- Confirm that the default sort is by date descending.
- Confirm that DataTables controls (paging, search, result count) work
  correctly.
- Confirm that clicking the "Filter paid transactions" link works
  correctly to toggle display of paid transactions.

Works as expected. Passed koha-qa.pl.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, no problems found.
Passes QA script and tests.

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

Bug 12258 Adds Datatables to the Fines->Account page of patrons (members/boraccount.pl). Also adds a button "Filter paid transactions" to hide fines with no outstanding value (0.00).

Test steps :

* Create a few manual invoices with fines.
* Pay a fine.
* Go back to the account tab.
* Try the "Filter paid transactions" button. It should filter everything with 0.00 in the Outstanding column.
* Try the "Show all transactions" button.
* Play around with the buttons

Followed test steps. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 9214 [Compiled CSS] Show damaged status in the OPAC for items which are not for loan

This patch contains the compiled opac.css file generated from the
revised LESS file in this bug's other patch.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 9214 - Show damaged status in the OPAC for items which are not for loan

Item statuses in the OPAC displayed according to a cascading hierarchy:
If something is lost it will appear as lost, "else if" it is checked out
it will appear as checked out, etc. I don't think there is a logical
reason why statuses should appear this way.

This patch modifies the logic in the template so that multiple statuses
can be displayed at the same time. The patch also wraps each status in
its own class so that libraries can apply custom CSS if they wish.

Some tweaks have been made to the LESS file adding some style to the
common "item-status" class for display of item statuses.

To test, apply the patch and view one or more titles in the OPAC which
have items with the following statuses: lost, checked out, damaged, not
for loan, waiting, on order, in transit, withdrawn, and available.

Modify items to have more that one status simultaneously, in particular
not for loan and damaged.

Also test the display of item statuses in the OPAC cart and the OPAC's
course details page (Course reserves -> [Course name]) since these pages
use the same include file.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12989: Fix JS error

inactive and active are not defined anymore. They should be removed. The
filter is done with DataTables.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12989: Update table footer with the visible rows - acqui-home

Note that bug 12984 changes the view of this table.

On the acqui-home page, the total was not updated.
With this patch, the footer (totals) will be updated on filtering rows.

Test plan:
1/ Go on the acqui home page.
2/ Verify the totals are correct.
3/ Filter the table using the filter input and verify the totals are
updated with the rows shown.
4/ Hide/Show inactive budgets and verify the totals are still corrects.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12984: Improvement of the funds list view - acqui home

Bug 11578 improved the funds list view in the administration module.
It would be great to have the same improvement on the acquisition
home page.

This improvement groups funds by budget and displays them with a
hierarchy.

Test plan:
0/ Create a budget and fund hierarchy, with active and inactive budgets.
1/ Go on the acquisition home page and verify the values are the same as
before
2/ Verify the funds are correctly listed
3/ Verify the links on top of table work (expand/collapse all, show/hide
inactive budgets).

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12988: Update table footer with the visible rows - budgets

On the budget list view, the total was not updated.
With this patch, the footer (totals) will be updated on filtering rows.

Test plan:
To test with both CurrencyFormat pref values.
1/ Go on the budget list view
2/ Verify the totals are correct.
3/ Filter the table using the filter input and verify the totals are
updated with the rows shown
4/ Hide/Show inactive budgets and verify the totals are still corrects.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.

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

Bug 13203: Plugin housekeeping: UNIMARC field 123i, 123j, 210c

In working on bug 10480, I noticed that these plugins needed some attention:

[2] unimarc_field_123i.pl: added missing template
[3] unimarc_field_123j.pl: resolved missing template with same file
[4] unimarc_field_210c_bis.pl: removed a warn, corrected some POD lines

Note about UNIMARC field 123i and 123j: Subfields $i and $j are each 8
characters long and contain the same components as subfields $f and $g
except that character position 0 contains a plus sign (for the northern
celestial hemisphere) or a minus sign (for the southern celestial hemisphere).

Test plan:
Connect unimarc_field_123i and 123j to some field.
Look especially at changing + or - for the hemisphere in the popup.
Check left-padding with zeroes for the other positions.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Checked plugin in a UNIMARC installation.

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

Bug 7673: DBRev 3.17.00.053

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

Bug 7673 [Terminology follow-up] New patron permissions to manage items

This bug adds a new preference, "SubfieldsToAllowForRestrictedEdition,"
but the use of the term "Edition" in this context is incorrect. I think
it would be more clear to change the preference name to
"SubfieldsToAllowForRestrictedEditing." This patch makes this change.

I realize this isn't a big issue since the preference has a good
description, but I thought that if we were going to make this as clear
as possible now would be the time to do it.

To test, start with a database which hasn't previously been used to test
Bug 7673. Apply all patches and run the database update. Follow the test
plan as described in the bug.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, change appears complete.
All tests and QA script still pass.

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

Bug 7673: add syspref in sysprefs.pl

Also fix a typo in the permission description

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patches pass QA script and tests.

Copying the test plan from the bug report:
Test plan:
1/ add the following permissions to the logged in patron:
edit_item, edit_items_restricted, delete_all_items,
items_batchmod, items_batchmod_restricted

2/ Fill the prefs SubfieldsToAllowForRestrictedEdition
and SubfieldsToAllowForRestrictedBatchmod with some
subfield (for instance "995$f 995$o" and "995$o")

3/ Verify you are allowed to edit the item fields defined
in the pref SubfieldsToAllowForRestrictedEdition.

4/ Try to edit item in a batch and verify you are allowed
to edit the item fields defined in the pref
SubfieldsToAllowForRestrictedBatchmod.

5/ Try to delete all items of a record

Play with the pref/permissions and verify they are
correctly taken into account.

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

Bug 7673: Assume that all fields can be edited if the pref is empty

If the sysprefs are empty, we assume that the librarian can edit all
subfields, even if s/he has the restricted permission.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: DB changes - Add permissions

This patch adds:
3 permissions:
- edit_items_restricted
- delete_all_items
- items_batchmod_restricted

2 system preferences:
- SubfieldsToAllowForRestrictedEdition
- SubfieldsToAllowForRestrictedBatchmod.

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: Change the superlibrarian check

To know if the user is a superlibrarian, we have to call
C4::Context->IsSuperLibrarian

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: Update permission names in script

Two permission names have been changed since the first patch.

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: Update syspref names in script

The both syspref names have been changed since the first patch.

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: the limitation on editing an item does not affect FA framework

The pref SubfieldsToAllowForLimitedEdition should not affect Fast
cataloguing framework (FA).

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: The delete all items link should only be displayed if delete_all_items is set

This test had been lost in a rebase.

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: QA Followup: trailing whitespace and perlcritic issues

This patch fixes the following qa issues:

 FAIL   cataloguing/additem.pl
   FAIL   forbidden patterns
        forbidden pattern: trailing space char (line 833)
   FAIL   critic
        # Variables::ProhibitConditionalDeclarations: Got 2 violation(s).

 FAIL   tools/batchMod.pl
   FAIL   critic
        # Variables::ProhibitConditionalDeclarations: Got 2 violation(s).

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 7673: New patron permissions

    This patch adds the following permissions:

     - editcatalogue.limited_item_edition: Limit item modification to barcode, status and note
     - editcatalogue.delete_all_items: Delete all items at once
     - tools.items_limited_batchmod: Limit batch item modification to item status

    The SubfieldsToAllowForLimitedEdition syspref is used to define which subfields can be edited
    when the editcatalogue.limited_item_edition permission is enabled.

    In the same way, the SubfieldsToAllowForLimitedBatchmod is used to define which subfields
    can be edited when the tools.items_limited_batchmod permission is enabled.

Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13113 [QA Followup] - Fix unit test

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13113 - Prevent juvenile/children from reserving ageRestricted material

There is no reason for underage borrowers to reserve ageRestricted material and
then be denied it's check-out due to ageRestriction.

This patch prevents reserving material for borrowers not suitably aged.

 # # # # # #
 # A PRIORI #
 # # # # # #
BOTH THE STAFF CLIENT AND THE OPAC
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You can reserve an ageRestricted Record with ease.
STAFF CLIENT ONLY
5. Check-in an Item from the ageRestricted Record and catch the reservation.
6. Check-out the ageRestricted Item for this underage Borrower.
7. You get a notification about being unable to check-out due to age restriction.
   How lame is that for a 12 year old?

 # # # # # # # #
 # A POSTERIORI #
 # # # # # # # #
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Check-out an ageRestricted Item for this underage Borrower.
4. You get a notification about having the maximum amount of reserves.
5. Place a hold for the underage Borrower for the ageRestricted Record.
6. You get a notification, that placing a hold on ageRestricted material is
   forbidden.

Includes Unit tests.

Followed test plan. Patch behaves as expected. (Note: Propagating error messages to template will be handled in Bug 13116 or 11999)

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13106 - Encapsulate Circulation::GetAgeRestriction() and modify it to check borrowers age as well.

This patch moves the logic of deciding whether or not a borrower is old enough to access this material
to its own function GetAgeRestriction.

This makes it easier to use AgeRestriction elsewhere, like with placing holds.

This feature adds a new function C4::Members::SetAge() to make testing ages a lot easier.
A ton of Unit tests included.

C4::Circulate::CanBookBeIssued() fixed and issue with undefined $daysToAgeRestriction per Marc Véron's
suggestion.

Test plan:
(See comment #10 for screenshots about using age restriction)

1) Without patch

Configure Age Restricition (see Syspref AgeRestrictionMarker) and have a biblio record with e.g. PEGI 99 in age restriction field
Try to check out to a patron with age < 99
Check out should be blocked
Change entry in age restriction field to PEGI99
Check out schould now be blocked

2) With patch
Try checkouts again, behaviour should be th same.

Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13176 - Add links "My account" and "My checkouts" for logged in user to drop down in staff client header

This patch adds links to "My account" and "My checkouts" to drop down in staff client header.

To test:
Apply patch
Got to drop down of logged in user (top right)
See new links to "My account" and "My checkout" (above "Log out")
Test the links.

Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Works as advertised. The options are not displayed when you are logged
in as the db/admin user.

Added classes "toplinks-myaccount" and "toplink-mycheckouts" to li tags to make it possible to hide them (per Kyle M $
Switching back to "Signd-off" (Hope this is OK becuause it is a tiny string addition)

Marc

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12987: The new format_price include file should be include on using datatables

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12987: Update table footer with the visible rows

This patch is the preparation step for others.

On acqui/acqui-home.pl and admin/aqbudgets.pl, it will be possible to
see the totals in the footer updated with the filtered rows.

Test plan:
This cannot be tested alone, you have to apply it with others (see the
"Blocked" bug reports).

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13018 : Static fine should be charged only once

Test plan (see Bug 6858 for using staticfine.pl) :

For a user (of a given category and library) with several overdues, launch the script :

staticfines.pl --category CAT,AMOUNT --library LIB --delay DELAY

Then, check that the user has been charged of AMOUNT if the due date of the most late item plus the delay is *before* today.

One day later, re-execute the script with the same parameters and check that the fine has not been charged twice.

Without patch, the fine is charged twice, with patch the user already charged is skipped (see output in debug mode)

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Without the patch, the fine will be applied every time the script is run.
With the patch the fine will only be applied once.
Passes tests and QA script.

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

Bug 13230: t/Biblio.t should run without a DB

This patch makes t/Biblio.t mock the DB connexion setting
a void one. All tests in this file currently call the C4::Biblio
functions with invalid (absent) parameters, so they are expected to
raise warnings and return undef values.

If someone writes mocked tests for the rest of the functionality,
it is expected to mock the DB calls to match the desired scenario.

To test:
- Turn of MySQL
- Run
  $ prove t/Biblio.t
=> FAIL: Tests fail because of missing MySQL server
- Apply the patch
- Run
  $ prove t/Biblio.t
=> SUCCESS: Tests now pass
- Start MySQL
- Run
  $ prove t/Biblio.t
=> SUCCESS: Tests still pass
- Sign off

Regards
Tomas

Sponsored-by: The will to procrastinate
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Sponsored-by: Wanting the darn packages to build
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Sponsored-by: Not wanting to read in my maths book
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12234 - dependency updates for master

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

Bug 12448: (RM followup) fix bug number in updatedatabase.pl

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

Bug 12986: Upgrade the DataTables jQuery plugin to the latest version (1.10.2)

DataTables 1.10.2 is now available.

The footerCallback function does not seem to work correctly with our
current version.

Test plan:
Go on the maximum of pages where DataTables is used and try to catch a
bug/regression :)

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I tested many many pages with DataTables, taking special care to find
pages with different DataTables configurations. I found no errors in the
OPAC or staff client.

Tested thoroughly in Firefox (latest) on Windows 7.
Tested less thoroughly in Chrome (latest) on Windows 7.
Tested briefly in Internet Explorer 7 in Vista and Internet Explorer 8
and found no bugs which were related to the DataTables upgrade.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>