Bug 7878 - When duplicating a patron too many fields carrying over

When duplicating a patron the resulting entry form contains the data
from the original patron in the following fields: Other names, Initials,
Gender, OPAC note, Staff note, and expiration date. These should be
blank for a new duplicated patron. This patch corrects this.

To test, locate or create a patron record which contains data in the
fields listed above. Duplicate that patron and confirm that those fields
are blank in the resulting patron entry form.

Confirm also that editing an existing patron with data in those fields
works correctly.

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 13279: t/Breeding.t shouldn't depend on the DB

Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13280: t/Circulation_barcodedecode.t shouldn't depend on the DB

Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13282: t/Message.t shouldn't depend on the DB

Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13283: t/Overdues.t shouldn't depend on the DB

Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13284: t/RotatingCollections.t shouldn't depend on the DB

Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 12505 - Variable aqorders.listprice in acq claim notice doesn't work

Modified:

C4/Letters.pm               - remove aqbooksellers.* from SELECT statement

In Letters - SendAlerts subrotine, is safe to remove aqbooksellers.* from SELECT statement
for type=claimacquisition or claimissues. Aqbooksellers is passed to GetPreparedLetter subrotine in tables variable.

Testing:

I Apply the patch

Select Tools -> Notices and slips;
Edit ACQCLAIM;
Add :
<order>Ordernumber <<aqorders.ordernumber>> (<<biblio.title>>) (<<aqorders.quantity>> ordered) ($<<aqorders.listprice>>  <<aqbooksellers.listprice>> each) has not been received.</order>
Save modifications;
Create a vendor (Acquisition module);
Create an order (Acquisition module);
Click Acquisitions -> Late orders;
Select the order created;
Click Claim order button;
Valide <<aqorders.listprice>>;
Valide <<aqbooksellers.listprice>>.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described. It's now possible to output the actual price
in the claim notice.

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

Bug 12505 - Acq claim: Show error message when no order is selected

If no order is selected on the acq claim page when clicking
'Claim order' an ugly perl error message is displayed.

This patch corrects the behaviour to display a human readable
'No order selected'
instead.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reworded commit message to reflect what the patch achieves.
Works as described and passes tests.

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

Bug 13055 - Show budget name when editing it

This patch adds the budget name to the page heading when editing a
budget. The patch also similarly corrects the page title during edit
operations and fixes some inconsistency in the breadcrumbs.

To test, edit an existing budget (Adminitration -> Budgets) and confirm
that page title, breadcrumbs, and heading look correct.

Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Nice improvement, works as described.

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

Bug 13261 - Better check in message for patrons with indefinite restricition

This patch adds a better check in message for patrons with indefinite restriction.

To test:
Check out an item to a patron.
Add a manual restriction without expiry date to that patron.
Check in the item.

Without patch, the checkin message reads:
Reminder: Patron was earlier restricted until 9999-12-31

Apply patch and repeat steps above.
The message should now read:
Reminder: Patron has a restriction (no expiry date)

NOTE: Changed wording at two places following Owen's  suggestion.  New: "Patron
has an indefinite restriction"

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Thanks Marc for catching this case. I was thinking like you that the wording
sounded strange while playing with bug 13242. Merge the original patch and the
followup, containing a better wording, thanks to Owen comment.

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 12701 - OPAC reading history still accessible by URL if turned OFF

If the opacreadinghistory system preference is turned off it is still
possible to navigate directly to the OPAC reading history page if you
know the URL. This patch adapts the fix for Bug 10595 (OpacTopissue page
still accessible when system preference is turned off) for
opac-readingrecord.pl

To test, log in to the OPAC and test the following conditions:

- With opacreadinghistory, navigating directly to
  /cgi-bin/koha/opac-readingrecord.pl should trigger a 404 error.

- With opacreadinghistory turned on there should be a working link to
  "your reading history" in the left-hand sidebar menu.

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and passes tests.

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

Bug 12703 - OPAC privacy page still accessible when the feature is turned off

If the OPACPrivacy system preference is turned off it is still possible
to navigate directly to the OPAC privacy page if you know the URL. This
patch adapts the fix for Bug 10595 (OpacTopissue page still
accessible when system preference is turned off) for opac-privacy.pl

Because the OPACPrivacy preference is irrelevant if opacreadinghistory
is not turned on, the patch adds a check for both to determine whether
the page should be accessible.

Log in to the OPAC and test under the following conditions:

 - OPACPrivacy is turned off, opacreadinghistory is turned off. Navigate
   directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
   error.

 - OPACPrivacy is turned off, opacreadinghistory is turned on. Navigate
   directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
   error.

 - OPACPrivacy is turned on, opacreadinghistory is turned off. Navigate
   directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
   error.

 - OPACPrivacy is turned on, opacreadinghistory is turned on. A link to
   both "your reading history" and "your privacy" should appear in the
   left-hand sidebar menu. Both pages should work.

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and qa script.

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

Bug 13289: document.write breaks DataTables

The document.write in a td seems to brake the page with a new version of
DataTables.

This patch replaces a dirty piece of code with another one (but this one
works...)

Test plan:
Create repeatable holidays and verify the page loads correctly.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Works to fix the problem. The code is definitely an improvement.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, fixes critical problem.
Passes tests and QA script.

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

Bug 13255: On-site checkout due date wrong if SpecifyDueDate is disabled

If you have the SpecifyDueDate preference disabled and check something
out as an on-site checkout the due date seems to follow the default
circulation rule rather than restricted the checkout to that day.

Test plan:
0/ Disable SpecifyDueDate and enable OnSiteCheckouts
1/ Check an item out to a patron and check the 'On-site checkout'
checkbox
2/ Verify (screen and DB) that the due date is correct (today 23:59)

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.

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

Bug 13303 - fix typo in debian/control

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

Bug 13277: (QA followup) use t::lib::Mocks

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

Bug 13277: t/SuggestionEngine_AuthorityFile.t shouldn't depend on the DB

To reproduce:
- Stop your MySQL server:
  $ sudo service mysql stop
- Run
  $ prove t/SuggestionEngine_AuthorityFile.t
=> FAIL: some tests fail because of mysql stopped

To test (MySQL still stopped)
- Apply the patch
- Run
  $ prove t/SuggestionEngine_AuthorityFile.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
            the absence of the DB server
- Sign off :-D

Regards

Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Turned off MySQL and ran the tests before and after the patch.
Works as advertized.

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

Bug 13278: (QA followup) use t::lib::Mocks

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

Bug 13278: t/Search.t shouldn't depend on the DB

To reproduce:
- Stop your MySQL server:
  $ sudo service mysql stop
- Run
  $ prove t/Search.t
=> FAIL: some tests fail because of mysql stopped

To test (MySQL still stopped)
- Apply the patch
- Run
  $ prove t/Search.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
            the absence of the DB server
- Sign off :-D

Regards

Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Turned off MySQL and ran the tests before and after the patch.
Works as advertised.

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

Bug 7143 : Updating history and about page

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Checked the names with git log and Bugzilla.

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

Bug 12132: display guarantees if a patron has them, regardless of category type

If a patron has guarantees, always display them on the patron summary,
even if the patron is of a type that ordinarily would have them.

For example, at present you can cannot directly add a guarantee to
a staff record the way you can do for an adult patron, but if you create
a juvenile patron and add a guarantor to it, you can override that
restriction.  Note that this patch ignores whether that is strictly
desirable behavior.

To test:

[1] Create a juvenile patron.  While editing it, make a staff
    account a guarantor of the new patron.
[2] View patron details for the staff account.  Note that the
    juvenile patron is not displayed as a guarantee.
[3] Apply this patch.
[4] Refresh details for the staff account.  The juvenile should
    now show up.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Galen patch works as described. The way it's implemented seems sensible.
Whatever the reason why a patron has guarantes, it make sense to display
them. So it's better to check the count of guarantes rather than the
current patron type to decide to display guarantes.

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

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

Bug 13223: [QA Follow-up] Adding some unit tests for wrapper

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Trivially amended. Thanks, Katrin.

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

Bug 13223: [QA Follow-up] Trivial change to one POD line

The line referred to Plugin while it should be FrameworkPlugin.
(I renamed the module in the process but forgot this line.)

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13223: Plugin housekeeping: do not redefine wrapper

This report is connected to bug 10480 which will change the general
mechanism of loading plugins, but can be tested independently and ahead
of that proposed change.

Several unimarc plugins use a wrapper sub. The code of this subroutine
is not exactly the same for all plugins: in some cases the routine is
extended for double character strings (dblspace and dblpipe). It would
not hurt to use the extended code for all plugins.

By moving the code to a module, we prevent redefinition
when two or more plugins are loading wrapper in a do-statement.

NOTE: You will not see wrapper redefine errors in your log, since the
plugins do not use the warnings pragma (yet). Since this patch touches
seventeen unimarc plugins, a unimarc signoff is preferred :)

Test plan:
Use some plugins changed in this patch (if not in use already).
Load the MARC editor.
Click on some tag editor-buttons to check unchanged behavior.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
               Unimarc plugins work as usual. No regression. Simple code
               factorization.

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

Bug 13039 - Vendor search: sorting of "item count" and "biblio count" columns can be incorrect

On the vendor search results page if some cells contain textual data the
"item count" and "biblio count" columns will sort incorrectly. This
patch sets an explicit numeric sort on these columns. In doing so this
patch also changes the existing column sorting configuration to use
table header cell classes instead of sorting based on index.

This patch also corrects two instances of unescaped ampersands.

To test, search for a vendor which has multiple baskets, at least one of
which should contain canceled orders. Confirm that sorting by item
count, biblio count, date, and closed all work correctly.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I have not been able to see the sorting problem, but the
patch causes no regression and everything seems to work nicely.
Passes QA script and tests.

http://bugs.koha-community.org/show_bug.cgi?id=12039
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13107 - Members are restricted even if the debarment is ended - opac-user

This is the same issue as bug 12134.

Test Plan:
1) Add a manual restriction to a patron with expiration date in the past.
2) Go on the OPAC and connect (opac-user.pl)
3) Note the warning message
    "Your account has been frozen until until XX/XX/XXXX ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.

NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.

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

Bug 13108 - Members are restricted even if the debarment is ended - opac-reserve

This is the same issue as bug 12134.

Test Plan:
1) Add a manual restriction to a patron with expiration date in the past
2) Go on the OPAC and connect
3) Try to add an hold on a record (opac-reserve.pl)
3) Note the warning message
    "Sorry, you cannot place holds because your account has been frozen ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Makes code cleaner, also works as described.

NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.

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

Bug 12376 - blinking cursor not clear in larger resolutions

This patch slightly alters the padding on <input> and <textarea> so that
the cursor is more visible.

To test, apply the patch and clear your browser cache. View a variety of
pages in the staff client and confirm that the change does not adversely
affect the display of forms.

Small change that enhances user experience.
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, small CSS change.

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

Bug 13234 [Follow-up] Make on-site checkouts visible in OPAC

This follow-up makes a few changes to the template:

1. The "show all" / "show 50" links have been modified to show the
   current state.
2. The tabs are only shown if the OnSiteCheckouts preference is turned
   on.
3. The DataTables configuration has been modified so that title sorting
   ignores articles, sorting on the the first column is disabled, and
   sorting by date works regardless of your dateformat preference.
4. Some indentation has been corrected and markup comments added.

To test the opacreadinghistory preference must be enabled. Log in to
the OPAC as a patron who has some on-site checkouts as well as regular
checkouts. With OnSiteCheckouts enabled, view the reading history page
and confirm that the tabs work correctly. Test the table sorting
controls.

With OnSiteCheckouts disabled, confirm that the tabs do not appear.

Test the "Show all items"/"Show last 50 items" links and confirm that
the behavior is correct.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, passes tests and QA script.
Good addition to the new on-site feature.

Note: It would be nice to show the 'on-site' note also in the
liste of checkouts on the summary page!

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

Bug 13234: On-site checkouts - OPAC

This patch introduces the code lost in bug 10860 for the OPAC side.

Test plan:
Go on opac-readingrecord.pl and verify the tabs work as expected and the
"show all items" and "show 50 items" links.

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 13242: Add a UT to t/DateUtils.t for testing DateTime bug

A bug in DateTime slow down drastically date parsing when the dates are in the
far distant future:

https://metacpan.org/pod/DateTime#Determining-the-Local-Time-Zone-Can-Be-Slow

This UT tests this situation which affects Koha::DateUtils function
dt_from_string() and output_pref().

TO TEST:
- Apply the patch containing the UT
- prove -v t/DateUtils.t
- You see that parsing a 9999-01-01 that take forever (ie more than 1s)
- Apply the patch containing the fix
- prove -v t/DateUtils.t
- No more complain.

Followed test plan. Test 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 - check-ins are now much faster.
Passes tests and QA script.

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

Bug 13242: Fix DateUtils for 'infinite' dates (ie year 9999)

TEST PLAN:

- Method 1--with UT

  - Use the UT associated to this bug, without applying this patch, and then
    after applying this patch

- Method 2--using Koha

  - Without this patch
  - Find a borrower with several checkouts that are not overdue.
  - Debarred the borrower
  - Go on circ/circulation-home.pl page
  - Select Check in tab, and do a check in
  - It required more than 20s to display the return.pl page
  - Apply the patch, and repeat previous steps
    => return.pl is immediately displayed.

Followed method 2. Time problem no longer exists.
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 13276: use t::lib::Mocks::mock_dbh

To use this patch, patch from bug 13274 should be applied too.

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

Bug 13276: t/XSLT.t shouldn't depend on the DB

To reproduce:
- Stop your MySQL server:
  $ sudo service mysql stop
- Run
  $ prove t/XSLT.t
=> FAIL: some tests fail because of mysql stopped

To test (MySQL still stopped)
- Apply the patch
- Run
  $ prove t/XSLT.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
            the absence of the DB server
- Sign off :-D

Regards

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tests pass without db connection for me now.

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

Bug 13274: Mock new_dbh in t::lib::Mocks

This patch suggests to create a routine to mock C4::Context::_new_dbh.

NOTE: Works the same with and without this secondary patch.
      koha-qa tests fine. Less cutting and pasting in the future.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Bug 13274: t/00-load.t shouldn't depend on the DB

To reproduce:
- Stop your MySQL server:
  $ sudo service mysql stop
- Run
  $ prove t/00-load.t
=> FAIL: some tests fail because of mysql stopped

To test (MySQL still stopped)
- Apply the patch
- Run
  $ prove t/00-load.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
            the absence of the DB server
- Sign off :-D

NOTE: Even seems to grab more than expected, which is good.
      349 tests in master vs 364 in this branch = 16,
      but removed block is only 13 (lines 20-32).
      Also ran koha-qa test tool. :)

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, tests passing now without database available.

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

Bug 12971 [QA Followup] - Fix error caused by patron not having any checkouts

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This successfully fixes the problem observed when a patron has no
checkouts.

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

Bug 12971: [QA Followup]

* Makes the status column display "Overdue!" if overdue
* Fixes the due date formatting
* Sorts the checkouts by date due ( oldest to newest )
  Note: I found no evidence that this data was previously sorted,
  so I kept it simple. Sorting based on system preferences could
  be a future enhancement.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This fixes the issues described for patrons with existing checkouts.

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

Bug 12971 - Regression: Patron print summary doesn't show checkouts

A patron's print summary should contain a list of checked out items
as it did in 3.16.2 and earlier.

Please note, as of 3.16.2 reserves were no longer part of the print
summary and thus are not part of this bug fixing patch.

Test Plan:
1) Find a patron with checked out items
2) Choose Print -> Print summary
3) Note the lack of a list of checkouts
4) Apply this patch
5) Reload the page
5) Print the summary again
6) Note the list of checkouts

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, apart from the missing status information
that Owen already noted on the bug.
Passes tests and QA script.

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

DBRev 3.17.00.057 (Koha 3.18 beta)

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

Bug 9043: DBRev 3.17.00.056

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

Bug 9043: The comma (,) should be kept to separate multi-valuated prefs

The prefs language and opaclanguages used the comma to separate the
different values.

The new prefs OpacAdvSearchMoreOptions and OpacAdvSearchOptions should
do the same.

To reproduce the issue: update the language pref (or opaclanguages) and
refresh the page.
=> The pref values are not checked anymore and the language selection
(bottom of the page) does not appear.

Test plan:
1/ Verify that the behavior described above is fixed.
2/ Verify that the original test plan of bug 9043 still passes.

Note: The 2 OpacAdvSearchMoreOptions and OpacAdvSearchOptions pref
values are overwritten but the feature have just been pushed recently.
It should not affect a production environment.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I was able to reproduce the issue and verify that this patch corrected
the problem. Langage selection and OpacAdvSearchOptions worked
correctly.

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

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>