Bug 11290: fix display of patron home page for certain translations

To test
1) In a fresh Koha, generate translation into XX
2) Select XX for the staff interface (i.e. enable it, and choose it)
3) Go to the Patrons page
4) Everything looks fine
5) In the admin page, create a patron category with any non-ASCII
   character.
6) Go back to the Patrons page, everything is broken
7) Apply patch
8) regenerate translation
9) Go back to the Patrons page, everything looks fine
10) Switch to english it still looks fine

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Tried with ru-RU and fixes the problem.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Problem is also visible on untranslated templates changing
one of the sample category descriptions to include diacritics.

[RM note: I wasn't able to reproduce this on an unstranslated
 template -- I tried using Arabic, Cyrllic, and Spanish characters]

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 3e1b781adc253722209e46385fb3248ae8d668f9)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11369 - Updating the jquery.cookie.js-plugin

The current jquery.cookie-plugin crashes when trying to fetch
all cookies using $.cookie();
Downloaded the newest plugin version and minified it.
Now works as intended.

Encountered an issue with the plugin now returning null when
no cookies are found, and applied a fix in browser.js.

-------------
- Test plan -
-------------
Plugin is used in browser.js and batchMod.js so testing both

Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 35bec75d66637bd3c4cff499ed7fb534b8d09f35)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11369: fix issue that can cause staff client searches to stop working

This patch fixes an issue where too many search cursor cookies overflow
the HTTP-header size after making multiple searches in the staff client.

To replicate this issue, make multiple searches in catalogue/search.pl.
50+ Should be enough to cause the HTTP-request header to overgrow.
One can verify this issue by observing the searchCookie growth in
browser's stored cookies.

-------------
- TEST PLAN -
-------------

Keep making searches.
One should never have more than 10 searchCookies. Browser might display
only 9, because for some reason the newest js-generated cookie is not
included in Firefox's cookies listing.

------------
- DRAWBACK -
------------

Removing these cookies disables the search cursor for traversing search
results (next/previous) for the removed cookie. This maybe be problematic
in some cases,
(for ex when multiple search tabs need to be open and they need to be
 traversed)
One easy solution is to grow the amount of stored searchCookies from 10 to
20, but 10 is chosen so there will be plenty of room for other cookies as
well.

Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 0cada7a323db7f9871b67a07e3343642543b64e0)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11369: (follow-up) Correct usage of me.searchid in browser.js

In browser.js, at creation of browser, the searchid is transmited to
JS object into me.searchid.
To be consistant, me.searchid should always be use, never searchid alone.
In browseRecords function, setting searchid as parameter is useless
because it is defined in me.searchid.

Test with test plan of Bug 10404

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 98edbf00cc10c908820eb1126a176ed12a04300d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11369: (follow-up) generate searchid in browser.js

The search browser feature uses nearly only the browser.js file.
That is why I propose to move the searchid generation from search.pl
to browser.js.
We then use Date.getTime() to use current timestamp as searchid,
prefixed by 'scs_' like before.

Test by using test plan of main patch :
Too many search cursor cookies overflow HTTP-header size, when
making multiple searches in the staff client

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Tested the browse functionality in staff by using the different
options (back to results, next, previous, etc) and the batch
modifications for items. An old cookie can cause a Javascript error,
but after restarting the browser/deleting cookies it all works
correctly.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit c4f17650132c9b74aa56c40a3a2bec2bdbc4477e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>