Bug 12481: Staff client detail-view "next" link is greyed out when the last search result of any results page is clicked or navigated into

When doing a staff client catalog search with more than 1 page of results
and clicking the last result on any search result page, the top-left navigation
button for "next" is greyed out.

Tested on newest Firefox & Chromium. Attempts to restore originally planned checks for navigation
with the exception of not using results.length due to buggy behaviour where the results get concatenated
upon page reload & "return to results" navigation - a separate issue?

To test:
1) Do an intranet catalog search that has more than 1 page of results.
2) Click on the last result on a page that is not the last one & confirm that the navigation button "next" is greyed out.
4) Apply patch.
5) Do an intranet search with more than 1 but less results than fit on a single page.
6) Click on the last result on the page and confirm that the "Next" navigation button is greyed out.
6) Do an intranet search with more than 1 page of results.
7) Click on the last result of a page that's not the final page of the results & confirm that "Next" is not grey out.
8) Navigate to the last page of the results and click on the final result & confirm that "Next" is greyd out.

http://bugs.koha-community.org/show_bug.cgi?id=12481

This patch prevents the "Next" button on detail view to be grayed out at the end of e result page.
Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12150 - Use more javascript string formatting in intranet for translated strings.

http://bugs.koha-community.org/show_bug.cgi?id=12150

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

No bug number on description
No commit message
No test plan
No koha-qa errors

I only signed this because it's useful for translations
but we can live without it, so is up to QA now

Tested some easy messages (e.g. syspref saving), and
updated PO files to check new strings.
Inspected the code, I think that there are no errors.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12150: Add missing space and correct innerHTML typo

The previous patch forgot to add a space between the string "Edit
action" and the placeholder.

Trying to test it, I found a typo: innerhtml does not exist, it should
be innerHTML.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 10652 - Ajaxfileupload.js failing in IE9 for local image upload

This patch adds a try/catch to the Javascript for adding the iframe
element. The try will work for IE8 and older versions, while newer
versions and other browsers will be covered by the check.

Test Plan:

1) Try uploading a local cover image in IE9
2) Notice that your page is reloaded with no result (except the
pop-up of a Javascript error, if you have error reporting on in
your browser).

3) Apply the patch

4) Trying uploading a local cover image again
5) Notice that it uploads correctly

6) Repeat steps 4 and 5 for IE8, IE7, and/or other modern browsers.

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

Tested in IE10 in IE10 "browser mode" and IE9 mode as well as in
Firefox. Uploads work correctly with book cover images and in MARC
uploads.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Also verified as working in Chrome.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Doesn't break functionality and fixes a known problem. I'll push this for
stable branches to use it, but will fill a new bug for updating AjaxFileUpload.js
from upstream.