Commit graph

28 commits

Author SHA1 Message Date
2bb09975bc Bug 5428: Jump back to the search result after deleting a record
This patch adds the ability to jump back to the search result after a
record has been deleted.
Also it keeps the "browser" when all items are deleted from a
bibliographic record

Test plan:
- Start a new search
- Select a record with items
- Delete all the items
=> You still see the browser
- Delete the record
=> You are back to the adv search form but we new link "Go back to the
results" is present at the top of the page

Limitation: As we delete the record we do not longer know the offset,
we are back to the first page of the result list

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-13 07:55:45 +02:00
6b6cea9d64 Bug 25031: Improve handling of multiple covers on the biblio detail page in the staff client
This patch modifies the template, JS, and CSS for the bibliographic
detail page in order to gracefully handle multiple cover images.

The changed version loops through any cover images which might be
embedded and checks that they are successfully loaded. Only
successfully-loaded images are shown. Only the first image is shown, and
the others can be "paged through" using generated navigation controls.

To test, apply the page and rebuild the staff client CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).

Enable multiple cover image services. The patch was developed with these
services available:

 - Amazon
 - Local cover images (including multiple local cover images)
 - Coce (serving up Amazon, Google, and OpenLibrary images)
 - Images from the CustomCoverImages preference

View a variety of titles and confirm that the cover images are
displaying correctly, whether there be 0, 1, 2, or more covers
available.

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-07-24 14:09:30 +02:00
2484fb6ac5
Bug 25016: Coce should not return a 1-pixel Amazon cover image
This patch adds an onload function to the JavaScript which loads images
from Coce. In the case where the image is 1 x 1 pixel the image should
be removed.

To test you should have Coce enabled and Amazon.com included in the list
of sources.

 - Apply the patch and view the bibliographic details page under a
  variety of conditions:
   - A title which has a matching Amazon image:
     - The image should load as expected.
   - A title which doesn't have a matching Amazon image
     - The image should not be found in the source at all after the page
       has loaded.
  - Test with local cover images enabled

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-17 09:28:49 +01:00
51dbb84a78
Bug 25027: Use localStorage instead of sessionStorage for results browser
Staff side, when a search a done and a result clicked, a browser appears
on the left, to navigate between the different results.

We use sessionStorage to know the list of biblionumber from the result.

As sessionStorage is only for the current tab, we do some ugly things,
to catch the click events, then open the new tab, attach it to the
current window, and put the focus back on the result list.

We really should not do that, and let the user decide what they want to
do with their clicks!

To do so, let use the correct storage, localStorage, and have the
results shared between the windows.

We may need to clear that at some point, isn't it?

Test plan:
Launch a search, click result (left or middle), confirm you see the
browser and that the window/tab opened like any other websites
(depending on your web browser settings).

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-14 16:13:38 +01:00
2e1e9c5b48
Bug 23601: Prevent default for auxclick
The issue appears to be that the default action is not prevented for middle click because it registers
an 'auxclick' event as opposed to a 'click' event

To test:
1 - Perform a search in staff client
2 - Shift-click and hold on a result
3 - Note a new tab opens
4 - Release the click, no change
5 - Middle click and hold on a result
6 - New tab opens
7 - Release, a second new tab opens
8 - Apply patch
9 - Reload page
10 - Middle click and hold
11 - New tab opens
12 - Release
13 - No new tab

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-06 10:59:56 +01:00
f1c93e88d4
Bug 24219: Preserve sort order when returning to result list
There is a mismatch between sort_cgi, sort and sort_by variables.

 * sort_cgi
I did not find relevant occurrences of sort_cgi in the git log of both
search.pl and results.tt. So it seems that it never worked correctly.
 * sort
It is the JS variable use in browser.js
 * sort_by is the search.pl parameter to set the sort_by option

Test plan:
1. Perform a search in the staff client
2. Change the sort order to something different (try Author A-Z)
3. Click on a result to view the record
4. Click on "Results" button on left side to return to result list
=> Without this patch the result list is sorted by relevancy
=> With this patch applied the Author A-Z is kept

Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-06 15:01:50 +00:00
Julian Maurice
9d6ec5c64b
Bug 21156: Add plural translation capabilities to JS files
It adds Javascript equivalent of Koha::I18N's exported subroutines, and
they are used the same way.

String extraction is done only on *.js files and require gettext 0.19
(available in Debian jessie, and also in wheezy-backports)

It adds Javascript library Gettext.js for handling translation and a
Perl script po2json to transform PO file into JSON.

Gettext.js and po2json both come from Locale::Simple.
There are several tools named po2json. It's simpler to integrate this
one into Koha than to check if the good one is installed on the system.
Locale::Simple is not needed.

To avoid polluting the global namespace too much, this patch also
introduce a global JS object named Koha and add some stuff in Koha.i18n

Test plan:
1. Add a translatable string in a JS file. For example, add this:
     alert(__nx("There is one item", "There are {count} items", 3,
     {count: 3}));
   to staff-global.js
2. cd misc/translator && ./translate update fr-FR
3. Open misc/translator/po/fr-FR-messages-js.po, verify that your
   string is present, and translate it
4. cd misc/translator && ./translate install fr-FR
5. (Optional) Verify that
   koha-tmpl/intranet-tmpl/prog/fr-FR/js/locale_data.js exists and
   contains your translation
6. Open your browser on the staff main page, change language and verify
   that the message is translated
7. Repeat 1-6 on OPAC side

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works well, translation is OK and test message is displayed correctly.
Current qa-tool error is a false positive.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-10 10:14:46 +00:00
Maryse Simard
47e48f3ade
Bug 18421: (follow-up) Center image in results table
Adds the "thumbnail" class to the image to have it centered.

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-07 14:09:12 +01:00
Charles Farmer
ef897b41f5
Bug 18421: (follow-up) QA fixes
Use the community's terminology, change coce.js's path, update <script>
to Asset, remove forbidden patterns

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-07 14:09:12 +01:00
2fade168c8
Bug 23438: Use Font Awesome icons in intranet search results browser
In intranet after a search you see a results browser top left of biblio record details.

Actually this uses text for links next and previous with a character for the arrows.
I propose to use Font Awesome icons arrows.

In fact the translated text is often too large for those buttons.
For example "Previous" is "Préédant" in french and it causes the next and previous buttons to display on two lines.
Using icons is more compact and easy to use.

This patch also adds the list icon to back to results link and changes for a minimal text "Results".

1) Go to intranet
2) Perform a search with a few results
3) Click on first record
4) Check browser displays well
5) Click on next icon, check you go to next search result
6) Click on revious icon, check you go to previous search result
7) Click on "Results", you come back to search results
8) Clik on "Last" and click on last record
9) Check browser displays well

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-13 11:39:57 +01:00
7236422768 Bug 21304: (follow-up) Fix style of search results browser
This follow-up revises the style of the search result browser in the
staff client, making it behave better at smaller browser widths.

The patch also makes a couple of ESLint-prompted changes to browser.js

To test, apply the patch and regenerate CSS.

 - Perform a catalog search in the staff client.
 - Click on one of the search results.
 - On the bibliographic detail page there should be results browsing
   controls in the left-hand sidebar.
   - Resize the browser window and confirm that the controls work well
     at various sizes.
   - Test with both the first and last search result.

Signed-off-by: Liz Rea <wizzyrea@gmail.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-22 19:15:44 +00:00
Katrin Fischer
880afc9035 Bug 19390: Make jQuery selector more specific, so OPAC view link can open in new tab
The OPAC view link in the staff result list already had a target="_blank",
but it didn't work, because of the JavaScript for the result list browser
in staff.

The JavaSript code was looking for the links to the detail page in staff
and this also selected the link to the detail page in OPAC. By changing
detail.pl to \detail.pl opac-detail.pl will no longer be selected.

To test:
- Search in the staff interface
- Click "OPAC view" links in staff result lists
- Click "OPAC view' links in detai page
- Verify both now open in a new tab
- Click other links and test that navigation (previous, next,
  return to results) works as expected
- Inside the staff client, you should see something like
  searchid=scs_1533922927978 added to the URLs

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Followed the test plan and it works.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-14 11:39:05 +00:00
c9a7b6742b Bug 19290: Browse selected bibliographic records - Staff interface
This patch adds the same feature as bug 10858 for the OPAC interface:
after a search, librarians will be able to browse selected results.
The results can be selected from several pages.
By extension it is possible to add results from several pages to a list
or the cart.

When at least one result is selected, a new "Browse selected records" button
becomes usable and change the behaviour of the existing browser.

The whole feature can be turned off with the pref BrowseResultSelection.

Test plan:
- Launch a search (on the staff interface)
- Check some biblios
- Go on another page
- Check some biblios
- Come back to a page you already check results and confirm that they are
still checked
- Click on the "Browse selected records" button
- Check that you are able to browse results you had checked.

You can also:
- add them to the cart
- add them to a list

QA note: the browsers at the OPAC and the one at the staff interface are completely different
That's why the code is not mimicking what has been done on bug 10858.
The behaviour must stay the same anyway.

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-19 16:13:30 -03:00
Hector Castro
2a6a3de7c4 Bug 16456: Add Font Awesome icons to some buttons in Tools module, section Patrons and circulation
Add Font Awesome Icons to section Patrons and circulation in Tools module.
Also correct a error dialog in JQuery functions

To test:
-Apply patch
-Goto Tools -> Patron list -> my_list_saved -> Add patrons -> Remove selected patrons,
 Clear all, Select all.
-Add new patron list and add some patrons, notice about the trash icon.
-Make some comments in some bib records and goto Tools->Comments
 you will presented with two tabs "Approved comments" and
 "Comments awaiting moderation".
 See the three new buttons: Approve, Delete, Unapprove.
-Set syspref TagsModeration to Require. This will show all pending tags to review.
-Make some tags in bib records and goto Tools -> Tags.
-Notice about the new look.
-In the new screen look the icons in buttons "Apply filter(s)", "Test", "Approved",
 "Reject". Notice about the new header bar above the DataTable with options: Select all,
  Clear all, Select all pending.
-Play with filters; Check if terms exist or not in appoved/rejected lists
-Play with Terms summary and see if DataTable is working as expected
-Click in some term tag with multiple titles
-A table with titles tagged with the term is presented
-See the new button 'Remove'
-Verify if you can remove tag from a selected title.
-Verify that all tools work as expected

NOTE: The Tag and Comments tools has been revised to fit with others
interfaces in Koha.
Bug ammended according with QA comment 5
Bug rebased because bug 16005
Test plan amended for clarity
Clock icon for "Select all pending" removed (QA comment 23).
Fix some forbidden patterns (tab char) in review.tt according by IRC comment
by Marc Veron

Followed test plan, looks and works as expected
Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-06-17 15:40:24 +00:00
Juan Romay Sieira
d1ead7313c Bug 11937 - opac link doesn't open in new window
Signed-off-by: Juan Romay Sieira <juan.sieira@xercode.es>

Patch works as expected. From a biblio detail page, the link
'OPAC view: Open in new window' opens a new browser window.
Signed-off-by: Marc Veron <veron@veron.ch>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
2016-02-24 02:49:36 +00:00
Jonathan Druart
41b9687d97 Bug 13265: Use sessionStorage to store searches instead of cookies
This is a counter patch.
The idea is to provide a permanent solution for the cookie length issue
we occurred on storing the searches (intranet side).

Test plan:
Launch as many searches as you can (don't forget to sleep).
You should not get any error.
Confirm there is no regression using the results browser.

Tested with 6 parralel searches in different tabs (with alternatively browising up and down). No problems found.
Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-06-11 10:06:45 -03:00
Jonathan Druart
e5858e16ec Bug 11890: Prevent default on click event
It seems that the previous patch does not stop the propagation of the
event if the link is clicked with the left button (which=1).

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-07 10:59:21 -03:00
Jonathan Druart
5218a0de08 Bug 11890: Click events on titles does not work as expected
The browse results feature (bug 10404) modified the click events on
titles on the search result page (intranet).

It introduced bad behaviors:
1/ ctrl+click on a title does not open a new tab
2/ middle click on a title does open a new tab but the browser is not
displayed.

Note that this patch is not perfect, it fixes the 2 bad behaviors but
the ctrl+click gives the focus to the new tab (could go against the
preferences of the users).

Test plan:
1/ On the staff interface, launch a search (catalogue/search.pl?q=XXX)
2/ When middle-clicking on a title, a new tab should open. On this tab
the browse result feature should be displayed
3/ Same for cltr+click

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-07 10:59:21 -03:00
Jonathan Druart
4d01620579 Bug 12944: Fix regression on translating
This patch fixes the translation for the "Remove" button.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Tested:
- acq history search with different searches
- patron lists patron search
Passes all tests and QA script.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-09 15:48:17 -03:00
Jonathan Druart
c8053f3c8d Bug 12944: Refactor the patron autocomplete
The patron list feature uses an autocomplete field to search patron.
This will be reused in the next patch.
This patch should not introduce any behavior change.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

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

Bug 12944 [QA Followup] - Rename patrons.pl to patrons.js

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

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-09 15:48:08 -03:00
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