Bug 11629 - Add ability to update not for loan status on checkin

Some libraries would like to streamline the cataloging process my
automatically updating notforloan values on checkin. For example, an
item is set to notforloan of -1 ( ordered ). The item, is received,
processed, and checked in for the first time before being shelved.
The checkin automatically changes the nfl value from -1 to 0. The
same workflow could be used for damaged items as well.

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Set the new system preference UpdateNotForLoanStatusOnCheckin
   to the following:
-1: 0
0: 1
4) Create an item, set its notforloan value to -1
5) Check in the item, note its not for loan value is now 0
6) Check in the item again, note its not for loan value is now 1
7) Check in the item again, note its not for loan value reamins 1

Signed-off-by: Havilah Lyon <havilah@aflibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: (follow-up) Add message for librarian that status was updated

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: (follow-up) add unit tests

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: (follow-up) remove <strong> tags to ease translation

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: (folllow-up) fix various issues

Changed the syspref.sql file to remove one of the doubled
up UNIMARCAuthrityField100 that slipped in with an earlier
patch on this bug.

Passes all tests and QA script, also t/db_dependent/Circulation_issue.t

Tested with items that had
- no notforloan value set
- notforloan value not used in updateNotforLoanStatusOnCheckin
- the notforloan value defined in UpdateNotForLoanStatusOnCheckin

Also verified it works the same, when the item was checked out or
not checked out on return.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: (follow-up) fix message displayed when item is made available

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11629: DBRev 3.17.00.007

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12312 - correctly upgrade under Apache 2.2

As the way we need to reference Apache instance names has now changed
between 2.2 and 2.4, we need to try it out both ways to make sure we get
it right.

This also allows koha-create/koha-disable to try the .conf version of
the name if the first one doesn't work.

To test:
* Create an instance on an Apache 2.2 system with koha < 3.16
* Upgrade to 3.16 with this patch, saying 'yes' to the renaming question
** Make sure you don't see the warning: Warning: problem enabling $site
   in Apache
* Do a 'service apache2 restart'
* Make sure you can still access the instance
* Make sure that /etc/apache2/sites-enabled/instance.conf exists as a link
  to /etc/apache2/sites-available/instance.conf
* Check that koha-create and koha-remove behave like you'd expect.

Note:
* If you need to make debconf forget that it asked you the question
  about renaming so that it'll do it again, then run:
  echo "unregister koha-common/rename-apache-vhost-files" | sudo debconf-communicate koha-common
* 'debconf-show koha-common' will show you the current debconf
  configuration.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: Add XSLT handler object to Koha namespace

In achieving the goals of umbrella report 6536 (Z3950 improvements), this
report adds a XSLT handler object to the Koha namespace.
A follow-up adds unit tests for this module.
This patch does not yet incorporate the new object into Z3950 search. So
it does not change any behavior and is therefore harder to test.

Test plan:
Run the unit tests of the follow-up patch on report 11826.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I tested the new module in two additional ways:

[1] Made a simple script (four lines as below) that ran a larger xml file
    with 1500 records through a test XSLT file modifying the title.

    my $eng= Koha::XSLT_Handler->new;
    open my $fh1, '<', '_example_file';
    my @xml= <$fh1>;
    print $eng->transform( join('', @xml), '_example_xsl_file');

[2] Incorporated the object into my local changes of Breeding.pm (based on
    older work, not ready for submittal now).
    Ran transformation on Z3950 search results. Worked well :)

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test runs Ok. No koha-qa errors.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: Add unit tests for Koha::XSLT_Handler

Test plan:
Verify if XSLT_Handler.t passes.
You could also sabotage the test by removing one of the test xsl files.
Or you could 'repair' the bad xsl file (test02). Remove the second line
redefining the xsl variable.
In all those cases the unit test should fail now.. Discard your changes :)

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test pass. No koha-qa errors.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: Use the XSLT handler in C4/XSLT module

Incorporate the new object into C4/XSLT module.
The handler object needed one adjustment to allow for passing URLs.
Removed the GetURI function; it is no longer needed.
Added some documentation lines.
Moved a file-level lexical upwards in the code for visibility.
Removed some tabs (on two lines).

Note: The handler could perhaps be moved up to the Context module, or
be saved in a global ('our') variable.  But I would rather not do that
now, making testing not too complex at this moment.

Test plan:
Enable XSLT preferences for opac and intranet.
Check result and detail pages.
Check individual list display (virtual shelves).
Force an XSLT error by editing one of your xsl files. Check the
corresponding display.
Put an URL in one the XSLT prefs (could just be to your own server).
Check the display.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Running XSLTParse4Display in a loop showed no significant performance
change.
One pass cost me around 0.012 sec (except for the first pass).

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Results, detail, url and list view Ok
No koha-qa errors

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: Use XSLT handler object in showmarc, Record.pm

Modifies showmarc and opac-showmarc to use new XSLT handler.
Removes cardview.pl as obsolete script.
Modifies C4/Record.pm and a typo in the test Record.t.

Test plan:
[1] catalogue/showmarc: Go to Cataloging. Search. Click Card.
[2] opac-showmarc: Go to opac detail, MARC view.
    Open URL for plain view in new tab.
    Change URL: Change viewas=html to viewas=card
[3] Verify that there are no references in the codebase to cardview.pl
[4] C4/Record.pm: Run the Record.t test in db_dependent.
    This test uses marc2modsxml, triggering the change.
    Additional: export to MODS from opac-detail.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Views Ok. Test pass. No more cardview. No koha-qa errors

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: (follow-up) enable printing warnings

Conform former (implicit) behavior the handler now prints warnings by
default (via STDERR to logfile).
This can be adjusted by: $engine->print_warns(0);

Test plan:
Generate some error on a XSLT file (e.g. wrong path).
Check if your log contains the associated error(s)/warning(s).

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11826: (follow-up) run perltidy on Koha/XSLT_Handler.pm

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6254: (follow-up) work-around to fix a failing test case

This patch ensures that a patron category that is present
in the (English) sample data is used for the ILS-DI tests,
avoiding a situation where one part of AddMember was trying
to access a patron category via DBIC but failed because
it was not visible to it yet.

Note that this will become easier once C4::Context->dbh
and DBIC are using the same base DBI database handles.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>