|
Description
Kyle M Hall (khall)
2021-09-08 15:03:54 UTC
Created attachment 124660 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Will it still be possible to print the whole queue over multiple pages? (In reply to Katrin Fischer from comment #2) > Will it still be possible to print the whole queue over multiple pages? Yes, you can choose the number of results per page. I think this needs some improvement. I have over 600 holds on my list. I first selected 10 rows per page and moved to page 3. Then I changed rows per page as 1000 assuming all holds would be displayed. Instead I got blank page. I had to switch back to 10 rows per page, go to page 1 and then select 1000 per page to see all of my holds. IMO it would be more user friendly to e.g. return to the first page if rows per page is changed. Otherwise this works fine. Created attachment 124864 [details] [review] Bug 28974: Start at first page when change number of results per page Created attachment 124874 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 124875 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125291 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125292 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125295 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125296 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125297 [details] [review] Bug 28974: Hard code page = 1 instead of using javascript Created attachment 125371 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125372 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125373 [details] [review] Bug 28974: Hard code page = 1 instead of using javascript Created attachment 125399 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125400 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125401 [details] [review] Bug 28974: Hard code page = 1 instead of using javascript Created attachment 125414 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125415 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125416 [details] [review] Bug 28974: Hard code page = 1 instead of using javascript Created attachment 125424 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125425 [details] [review] Bug 28974: Start at first page when change number of results per page Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Created attachment 125426 [details] [review] Bug 28974: Hard code page = 1 instead of using javascript Created attachment 126277 [details] [review] Bug 28974: (follow-up) Pass total number of items instead of count per page Before pagination the count of items was the same as the total, now they will differ Make sure to pass $total to the template instead fo the count per page There is an issue with the depending bug needing some more work, but this also doesn't apply cleanly on top: Bug 28974 Depends on bug 28966 (Signed Off) Follow? [(y)es, (n)o] y Bug 28966 - Holds queue viewer too slow to load for large numbers of holds 125377 - Bug 28966: Prefetch patron data for holds queue viewer Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 28966: Prefetch patron data for holds queue viewer Bug 28974 - Add pagination to holds queue viewer 125424 - Bug 28974: Add pagination to holds queue viewer 125425 - Bug 28974: Start at first page when change number of results per page 125426 - Bug 28974: Hard code page = 1 instead of using javascript 126277 - Bug 28974: (follow-up) Pass total number of items instead of count per page Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 28974: Add pagination to holds queue viewer error: sha1 information is lacking or useless (C4/HoldsQueue.pm). error: could not build fake ancestor Patch failed at 0001 Bug 28974: Add pagination to holds queue viewer hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-28974-Add-pagination-to-holds-queue-viewer-HdA_x4.patch Created attachment 168355 [details] [review] Bug 28974: Add pagination to holds queue viewer We have a partner processing thousands of holds per day, per branch. At this number of holds, the script loads very slow if it manages to load at all. Paginating the results of the holds queue will allow this page more flexible and load more quickly. Test Plan 1) Generate a lot of holds in the holds queue 2) Apply this patch 3) Try out the new pagination bar 4) Ensure the limit and page features function correctly Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi> Rebased and squashed follow-ups The pagination is working but the datatables features (filter, sort) only work on a single page. I think this can be confusing for users (when I click on a column header to sort, I expect the whole table to be sorted). It's still better than not being able to load the page at all I guess, but it will not be seen as an improvement for users that have more than 20 holds in that table and no problems loading it. Would it be difficult to turn this table into a full server-side/AJAX (filter, sort, pagination) table ? |