Commit graph

8 commits

Author SHA1 Message Date
Juhani Seppälä
3e0e65ca10 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>
2014-07-03 09:52:33 -03:00
Juhani Seppälä
fa5bc09926 Bug 12261: Staff client next/previous links lead to unknown record
When using Staff client next/previous links after a search :
If the current record is the last of the results, clicking on "next"
will lead to the page of an unknown record with message :

The record you requested does not exist (NaN).

To test:
1) Do an intranet catalog search that has more than 1 results.
2) Click on the last search result and then click the "Next"-button from
   the top-left navigation.
3) Confirm that you get thrown to a page with the message: "The record
   you requested does not exist (NaN).".
4) Apply patch.
5) Repeat steps 1 - 2.
6) Confirm that the navigation button for "Next" is greyed out.

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

This patch fixes the problem with last result in both single pages of
search results and multiple pages of search results.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-06-21 18:53:19 -03:00
c4f1765013 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>
2014-05-02 23:19:59 +00:00
98edbf00cc 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>
2014-05-02 23:18:55 +00:00
Olli-Antti Kivilahti
0cada7a323 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>
2014-05-02 23:17:04 +00:00
Olli-Antti Kivilahti
35bec75d66 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>
2014-05-02 23:15:55 +00:00
8acce47efc Bug 10404: tweak style of staff client previous/next links
This patch slightly modifies the styles of the previous/next links in a
way that I think is simpler and clearer.

To test, apply the patch and clear your browser cache if necessary.
Perform a search in the staff client, click any result, and look at the
prevous/next links.

Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-08-09 15:08:49 +00:00
Jared Camins-Esakov
762c3304ea Bug 10404: add previous/next browsing to staff client
Although previous/next browsing was added for searches in the OPAC
in 2011, the staff client has been without any sort of search browsing.
Until now. This patch is an all-singing, all-dancing, all-compatible
implementation of search browsing that will work across multiple
browser tabs and on any browser since IE7 (though the staff client
layout is broken on IE7).

To test:
1) Perform a search that will bring up multiple results.
2) View one of the results.
3) Use the Previous and Next links to browse along the search results.
4) Use the "Return to results" button to check that you end up at the
   correct page of results, even if you page through more than 20
   records.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-08-09 15:07:39 +00:00