---- Reported by email@example.com 2008-02-06 13:53:56 ----
Especially noticeable in tools/manage-marc-import.pl ... A large number of pages causes a big block of page links to usurp the page.
Perhaps there's a yui component that can handle this for us ?
Or a two-level pagination display.
---- Additional Comments From firstname.lastname@example.org 2008-09-25 07:37:45 ----
Since Koha uses a pagination script to generate these links, perhaps that should be the focus rather than looking for a client-side fix?
---- Additional Comments From email@example.com 2008-09-26 00:58:49 ----
Created an attachment
This is an import of 20,000 records, with 661 pages of results.
---- Additional Comments From firstname.lastname@example.org 2008-10-01 10:55:07 ----
See line 548 of catalogue/search.pl: "## FIXME: add a global function for this, it's better than the current global one."
--- Bug imported by email@example.com 2010-05-21 00:34 UTC ---
This bug was previously known as _bug_ 1817 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1817
Imported an attachment (id=373)
Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
an account here. Reassigning to the person who moved
it here: firstname.lastname@example.org.
Previous reporter was email@example.com.
The original submitter of attachment 373 [details] is unknown.
Reassigning to the person who moved it here: firstname.lastname@example.org.
Created attachment 8211 [details]
file iso unimarc with notices bib for test (block 10%)
Could we use server site processing with data tables here?
(In reply to comment #2)
> Could we use server site processing with data tables here?
Yes, we could. But implementing server side processing is not a trivial job.
An easy fix would be to hide some page numbers (for example start + 10 to end - 10).
This tool now uses datatables, so this does not apply anymore.