The Holds to Pull report table of results has a filter bar which only appears at the end of each page of results. In systems where there are a lot of libraries/branches, this can mean scrolling a long way to allow the user to filter to show results from their library/branch, or to filter in another way. Possibly related to Bug #35139 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35139
Created attachment 168175 [details] [review] Bug 37148: Moved filter bar to the top of Holds to Pull report table.
To Test: 1. Go to Circulation -> Holds to pull 2. Notice filter bar is at the bottom of the table. 3. Apply patch, restart_all 4. See filter bar at the top of the table.
Instead of putting the filters into the same <thead>, I recommend just doing a new <thead></thead> underneath the existing one and then putting the filter code in there. This makes everything less crowded and with the current patch, it's hard to see what you type in for some of the filters, specifically "Pull this many items".
Looks like the patch breaks the Columns drop down menu of the Hold to pull report. After applying the patch to a sandbox, Columns menu only has the little check marks without the column names. I tried with two PTFS Europe's sandboxes.
We're going to resurrect this one
Created attachment 170759 [details] [review] Bug 37148 - Move hold to pull column filters to top This bug moves the column filters on the holds to pull page (pendingreserves.pl) to the table header, similar to how it is being done on shelves.pl. This should make it much clearer to users that filtering is possible, and also make the filters float on the page, so they are always visible. To test: a) apply half a dozen holds, with varying item types, shelving locations, holding branches, titles, and collections b) go to pendingreserves.pl c) notice that the filters are in the table's footer, and that you have to scroll down to see them d) APPLY PATCH e) notice that on pendingreserves.pl, the filters present in tfoot are now in thead f) notice that the filters are unchanged, aside from location on page g) notice that the filters now stick to the top of the page, like the headings did h) notice that the headings still change the sort order when clicked i) notice that the filter inputs all still work as expected j) SIGN OFF! :-)
Could we consider doing this to all tables with the filter options? I think they never really make sense at the bottom: when I have so many results I want to filter, I don't want to have to scroll down first.
Agreed; it seems silly to have them at the bottom. Let's get this signed-off, and then I can work on a separate omnibus bug for the rest of them? Jake.
Do we need to obsolete the first patch here now Jake?
(In reply to Martin Renvoize from comment #9) > Do we need to obsolete the first patch here now Jake? Answer: Yes.. the new patch is a fresh patch.
Created attachment 170955 [details] [review] Bug 37148 - Move hold to pull column filters to top This bug moves the column filters on the holds to pull page (pendingreserves.pl) to the table header, similar to how it is being done on shelves.pl. This should make it much clearer to users that filtering is possible, and also make the filters float on the page, so they are always visible. To test: a) apply half a dozen holds, with varying item types, shelving locations, holding branches, titles, and collections b) go to pendingreserves.pl c) notice that the filters are in the table's footer, and that you have to scroll down to see them d) APPLY PATCH e) notice that on pendingreserves.pl, the filters present in tfoot are now in thead f) notice that the filters are unchanged, aside from location on page g) notice that the filters now stick to the top of the page, like the headings did h) notice that the headings still change the sort order when clicked i) notice that the filter inputs all still work as expected j) SIGN OFF! :-) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
All works as described.. so signing off. However, the commit message format is wrong.. remember to run the QA script against your patches Jake.. it'll highlight that sort of minor error (: instead of - please ;P ) I wonder about generalising as Katrin has asked.. though I can't entirely remember how these bits fit together right now.
So.. we actually already have the 'add_filters' option available to us in the KohaTable component.. however for some reason it doesn't work as expected for this table. I think this patch is OK as is.. but we could investigate why it doesn't work here if we wanted.. or just not worry and leave it to the ajax tables when that eventually rolls around to this particular case?
Ah, nicely spotted — you might need to show me where to find those QA scripts and the best options to use :-)