Bug 9924 - Simplify and rename patron card creator error message include

The patron card creator error message include uses a non-standard method
for displaying error messages, and is poorly-named.

This patch converts the method of displaying error messages for various
patron card creator options to the standard one ('<div class="dialog
alert">') and renames the include file to make it clear that it relates
only to patron card creator operations.

To test, perform various operations:

- Go to 'manage images' and try to upload a file which exceeds the
  500KBfile size limit
- Go to the edit batch page and manually append an error code to the
  URL:  /cgi-bin/koha/patroncards/edit-batch.pl?op=new&error=403
- Go to one of the manage pages and manually append an error code to the
  URL:
  /cgi-bin/koha/patroncards/manage.pl?card_element=profile&error=201

Correct display of an error message indicates that the include file is
being found.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes test plan, test suite and QA script.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9924: (follow-up) ensure that correct error message is displayed

(Apparently) unlike HTML::Template::Pro, Template Toolkit doesn't like
template variables that are entirely numeric -- in conditionals, it
consider them integers, most of which are Perl true.

This patch changes this by setting the error variable to the error
value.

To test:

[1] Run the test plan from the previous patch.  In each
    case, verify that the error message is specifically applicable
    to the test.  For example, if you try uplaoading a patron image
    that is larger than 500KB, the error message displayed should
    specifically say so.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Thank you Galen for catching this. Error messages showing up
now are much more specific and according to the error codes given.
I testd uploading a file larger then 500KB and triggered several
error messages giving the error code in the URL:
/cgi-bin/koha/patroncards/manage.pl?card_element=profile&error=201

All tests and QA script pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10331 - Little errors in unimarc_field_4XX.pl (punctuation)

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described, no koha-qa errors

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Copying the test plan from the bug report:

A.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 700 $a, $b, $f filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
  fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (no closing bracket)

B.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 700 $a, $b, $c, $f filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
   fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (dash instead of
   semicolon between original $c and $f, no closing bracket)

C.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 702 $a, $b, $c filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
   fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (unnecessary semicolon
   after original $c, n.b. lacking space).

D.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 712 $a, $b filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
   fetch data from biblio rec. mentioned in b)
4) see the punctuation in $a -- it will be wrong (unnecessary opening
   bracket at the end).

Test plan, all tests and QA script pass.
Thx Bernardo for his testing and explanations!

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10564 - use OPACURLOpenInNewWindow in UNIMARCslim2OPACResults.xsl

When using UNIMARC XSLT for OPAC detail page, if record has an 856$u,
its content is displayed as a link. The syspref OPACURLOpenInNewWindow
adds the option of opening in a new window (attribute target="_blank").

856$u is also used in UNIMARC results XSLT but the use of
OPACURLOpenInNewWindow syspref is missing. It exists for MARC21.

This patch adds the use of OPACURLOpenInNewWindow in UNIMARCslim2OPACResults.xsl.

Test plan :
- In a UNIMARC catalog, enable XSLT for OPAC results page
- Create a record with a link in 856$u and set second indicator to 0
- Set OPACURLOpenInNewWindow syspref on
- At OPAC, perform a search that contains the record
=> You should see the link : "Click here to access online"
- click on it
=> You shoud get to a new window (or tab depending on your browser configuration)
- Set OPACURLOpenInNewWindow syspref off
- re-perform the search
- click on the link
=> You shoud stay in same window

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Comment: Work as described, no koha-qa errors
Tested following plan after applying patch

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
XSLT change only, works as described.
To test: Catalog 856$u and $a, 2nd indicator = 0.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10817: return hold items info in SIP Patron Info Response

When requested by the summary flags the sipserver
should return in the patron info response barcodes of
the relevant titles.

For available holds this is the barcode of the captured items.

For unavailable holds ( i.e. current unsatisfied holds ),
we need to send a barcode so that the unit can use this to
request the title info. The barcode could be any one
belonging to the title.

This patch also corrects the erroneous return of empty items
in the patron information response. If the unit supplies a
range 1 - 100 unless the title has a hundred or more copies the
unit expects all copies. The server was erroneously stuffing
the returned arrays with null copies so that all summary requests
returned 100 copies (mainly without barcodes)

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

Testing notes:
Using the test script provided on the bug report, but changed it
to match sip user and patron existing in my database.

Before applying the patch the SIP responses show the behaviour
pointed out above regarding the 100 items. After applying the
patch and restarting the SIP server responses are much more clean
not returning empty IDs.

64 Patron information response
AS = hold items
  hold items count is correct.
  AS contains barcodes of waiting holds.
  Before patch, all AS were empty.
AT = overdue items
  overdue items count is correct.
  AT contains barcodes of overdue items.
AU = charged items
  charged items count is correct.
  AU contains barcodes of charged items.
AV = fine items
  Judging from behaviour seen and comment in
  Patrons.pm currently not implemented.
BU = recall items
  Recalls are not implemented in Koha yet.
CD = unavailable hold items
  unavailable items count is correct.
  CD contains barcode for item level holds and is empty
  for title level holds where  no item can be determined.
  Before patch, all CD were empty.

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