Bug 12071: improve generation of Z39.50 search links

This patch fixes two problems with the generation of
links to execute a Z39.50 search from the staff client
catalog and cataloguing search results page.

First, if using URI::Escape 3.30 or earlier, performing a simple search
with a double quote (e.g., "histoire algerie"), the Javascript is broken
in results page because of :

function GetZ3950Terms(){
  var strQuery="&frameworkcode=";
  strQuery += "&" + "title" + "=" + ""histoire%20algerie"";

Second, the encoding of non-ASCII characters in the search
term was broken.

This patch moves URI escaping from Perl to template with uri TT filter.

Test plan :
- To reproduce the issue with double quotes, the server
  must be running URI::Escape 3.30 or earlier; the current
  version of URI::Escape properly escapes double quote.
- In staff interface, perform a search with double quotes
  that will return no result, ie "aaa xxx"
=> Without patch, javascript is broken
=> With patch, javascript is not broken
- Click on Z3950 button on results page
=> Without patch, the Title input is empty
=> With patch, the Title input contains the search terms

Additional test:
Do a search with something like äöü and then click Z3950
button on results page.
Without patch, encoding is broken in Z3950 form
With patch, encoding is correct.

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed a few tabs. Passes tests and QA script.
I can't reproduce the Javascript problem, but I can reproduce
the Z39.50 encoding problem and can detect no regression.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 064d5478d31b05442e19b7d57f0af94d3422731e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11947 - renumber reserves when hold is confirmed

Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.

This patch forces a renumbering so that all the priorities remain
copacetic.

Test plan:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Test plan confirms that the problem exists and that the patch corrects
it.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/db_dependent/Reserves.t.
Improves priority calculation.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 95056d17b715b74e3f7149d60e12d5a365d70eeb)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 12079: ensure that CheckReserves() includes reserve_id in its response

This patch modifies _Findgroupreserve so that its one caller,
CheckReserves(), would include the reserve_id field in the
hold request it returns.

Failure to include reserve_id in every circumstance resulted
in bug 11947.  This patch is therefore a complementary fix for
that bug, but is not meant to preempt the direct fix for
that bug.

To test:

[1] Verify that t/db_dependent/Reserves.t passes.
[2] Verify that the following test plan taken from
    the patch for bug 11947 works for this patch
    *without* applying the patch for 11947:

* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.

Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".

With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Work as described. No koha-qa errors. Test pass

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 695fdebdee802387f45505a1350120727d3e2f7f)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>