When using DataTables it would be useful to provide a way to link to the paginated and filtered results. Especially when rows are retrieved from the REST API (server-side processing).
Created attachment 115325 [details] [review] Bug 27467: [SOLUTION 1] Add dataTables.keepConditions.js
Created attachment 115326 [details] [review] Bug 27467: [SOLUTION 1] Don't repeat port This patch fixes a bug in the keepConditions plugin
Created attachment 115327 [details] [review] Bug 27467: [SOLUTION 1] Use keepConditions This first solution use a non longer maintained plugin: https://github.com/jhyland87/DataTables-Keep-Conditions/ I've tried to make it works with the column filters. But actually even with the general search filter the table is not correctly filtered. I guess it's related to their issue 1 https://github.com/jhyland87/DataTables-Keep-Conditions/issues/1 To test: Go to the cities page Use the general search filter Copy the URL and open it in a separate tab => The filter is kept but the REST API query is not built using it
Created attachment 115328 [details] [review] Bug 27467: [SOLUTION 2] Add deepLink.js
Created attachment 115329 [details] [review] Bug 27467: [SOLUTION 2] Using deepLink.js This solution is based on https://github.com/DataTables/Plugins/tree/master/features/deepLink https://datatables.net/blog/2017-07-24 I was expecting it to let us provide the columns filters using the following query (that would filter on name="cit"): /cgi-bin/koha/admin/cities.pl?columns=[{"search":""},{"search":"cit"},{"search":""},{"search":""},{"search":""},{"search":""}] But it does not work. In my understanding this will also set the data for each columns. As they are not in the URL, DT is using undefined value (hence the "data is undefined" JS error)
Created attachment 115330 [details] [review] Bug 27467: [SOLUTION 3] Use stateSave Based on https://stackoverflow.com/questions/55446923/datatables-1-10-using-savestate-to-remember-filtering-and-order-but-need-to-upd/60708638#60708638 (I removed the atob and btoa call) This solution is finally working but it's not the ideal one IMO. Using stateSave will modify the URL when the user modifies the table's settings. We would prefer to not modify it but have a "Copy link" buttons on top of the table instead.
Created attachment 115331 [details] [review] Bug 27467: [SOLUTION 3] Put filter values into the column filters
I find this interesting, but am still intrigued by the use case that would benefit from this. I guess is coming back from receiving an order, for example? Is that what you have in mind?
We are starting to modify our tables to use the REST API routes. That will replace our GET parameters and users won't be able to share what they really see (copy/pasting the URL). The first example is parcel.pl, yes. But more will certainly come.
(In reply to Jonathan Druart from comment #9) > We are starting to modify our tables to use the REST API routes. > > That will replace our GET parameters and users won't be able to share what > they really see (copy/pasting the URL). > > The first example is parcel.pl, yes. But more will certainly come. I totally agree here. Haven an option to link to exact spots in Koha is really great for a lot of things. We use this a lot in reports, but also of course in support. I'd love if this worked in a transparent way for the datatables.
(In reply to Tomás Cohen Arazi from comment #8) > I find this interesting, but am still intrigued by the use case that would > benefit from this. I guess is coming back from receiving an order, for > example? Is that what you have in mind? I'd like some examples too. I don't understand the concept.
(In reply to David Cook from comment #11) > (In reply to Tomás Cohen Arazi from comment #8) > > I find this interesting, but am still intrigued by the use case that would > > benefit from this. I guess is coming back from receiving an order, for > > example? Is that what you have in mind? > > I'd like some examples too. I don't understand the concept. I got it. Take the order receipt in acquisitions, you search for an order, receive it, you want to go back to the receive table with the filters you already worked on. So Jonathan proposes some way to prefill the filters, basically, without much work for the devs. Do you can create an usable link to a page that loads the datatable, with the filters already applied. The specific case would not be needed as per bug 8179, but there are certainly some areas that could benefit.
Filters, pagination, order, etc. The current state of a DataTable-base table. The use case I had in mind was more about sharing a table with a colleague. With "Solution 3", when the state changes, the URL of the page is updated and become something like: http://kohadev-intra.mydnsname.org:8081/cgi-bin/koha/acqui/parcel.pl?invoiceid=1&pending_orders_state=%7B%22time%22%3A1612937360234%2C%22start%22%3A10%2C%22length%22%3A10%2C%22order%22%3A%5B%5B0%2C%22asc%22%5D%5D%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%2C%22columns%22%3A%5B%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22h%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%2242%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%2C%7B%22visible%22%3Atrue%2C%22search%22%3A%7B%22search%22%3A%22%22%2C%22smart%22%3Atrue%2C%22regex%22%3Afalse%2C%22caseInsensitive%22%3Atrue%7D%7D%5D%7D Yes, it's ugly, but it contains the values of the different column filters. But any of your colleagues with the link can see the same table as you: https://snipboard.io/7pILMF.jpg
Right.. so solution 3 is the one that works.. we should drop solutions 1 and 2 to clarify what people should be testing. Silly question.. why drop the base64 encode/decode? I find that string a less ugly than the URL encoded set or state params myself.. So.. what's waiting to happen here to push this from 'In discussion' into 'Needs signoff' ?.. is it the addition of a 'Share' button?
(In reply to Martin Renvoize from comment #14) > Right.. so solution 3 is the one that works.. we should drop solutions 1 and > 2 to clarify what people should be testing. I was expecting more love on this one and so maybe follow-up to improve what I wrote. Hence the different versions and explanations. > Silly question.. why drop the base64 encode/decode? I find that string a > less ugly than the URL encoded set or state params myself.. Do you prefer the URL above or this one? I prefer the first one, at least you can read it. But I am not attached to it. http://kohadev-intra.mydnsname.org:8081/cgi-bin/koha/admin/cities.pl?table_cities_state=eyJ0aW1lIjoxNjE1Mjg2NDk4ODU1LCJzdGFydCI6MCwibGVuZ3RoIjoyMCwib3JkZXIiOltbMSwiYXNjIl1dLCJzZWFyY2giOnsic2VhcmNoIjoiIiwic21hcnQiOnRydWUsInJlZ2V4IjpmYWxzZSwiY2FzZUluc2Vuc2l0aXZlIjp0cnVlfSwiY29sdW1ucyI6W3sidmlzaWJsZSI6dHJ1ZSwic2VhcmNoIjp7InNlYXJjaCI6IiIsInNtYXJ0Ijp0cnVlLCJyZWdleCI6ZmFsc2UsImNhc2VJbnNlbnNpdGl2ZSI6dHJ1ZX19LHsidmlzaWJsZSI6dHJ1ZSwic2VhcmNoIjp7InNlYXJjaCI6Im5hbV8iLCJzbWFydCI6dHJ1ZSwicmVnZXgiOmZhbHNlLCJjYXNlSW5zZW5zaXRpdmUiOnRydWV9fSx7InZpc2libGUiOnRydWUsInNlYXJjaCI6eyJzZWFyY2giOiIiLCJzbWFydCI6dHJ1ZSwicmVnZXgiOmZhbHNlLCJjYXNlSW5zZW5zaXRpdmUiOnRydWV9fSx7InZpc2libGUiOnRydWUsInNlYXJjaCI6eyJzZWFyY2giOiIiLCJzbWFydCI6dHJ1ZSwicmVnZXgiOmZhbHNlLCJjYXNlSW5zZW5zaXRpdmUiOnRydWV9fSx7InZpc2libGUiOnRydWUsInNlYXJjaCI6eyJzZWFyY2giOiIiLCJzbWFydCI6dHJ1ZSwicmVnZXgiOmZhbHNlLCJjYXNlSW5zZW5zaXRpdmUiOnRydWV9fSx7InZpc2libGUiOnRydWUsInNlYXJjaCI6eyJzZWFyY2giOiIiLCJzbWFydCI6dHJ1ZSwicmVnZXgiOmZhbHNlLCJjYXNlSW5zZW5zaXRpdmUiOnRydWV9fV19 > So.. what's waiting to happen here to push this from 'In discussion' into > 'Needs signoff' ?.. is it the addition of a 'Share' button? Yes, but first I wanted feedback from people. Looks like it didn't get unanimity on its usefulness.
Created attachment 117962 [details] [review] Bug 27467: [SOLUTION 3] Restore atob/btoa calls
Hi all, I'm looking at this. It is an important addition.
(In reply to Tomás Cohen Arazi from comment #17) > Hi all, I'm looking at this. It is an important addition. So?
I'm quite disappointed that bug 14322 got attention when this one didn't :( Haveing a general solution would be so much better than the single table solution proposed, and now pushed, in the other bug :(
I think it's important we make an effort to move this. @Joubu patches no longer apply, are you available to rebase? As I understand it, the preferred solution for now is #3 though personally I would like to at least have one go at #2. Regardless of the solution adopted, and pardon me if this is a dumb question, but do we run the risk of encountering possible issues with browser URL character limits if the query has too much stuff in it? Possibly something to address only if/when it becomes a problem.
I've done some testing with #2, it appears having deepLink using column names is not possible? I wasn't able to get it working (using cities). I can get these to work using Joubu's patches: http://localhost:8081/cgi-bin/koha/admin/cities.pl?search.search=pedro http://localhost:8081/cgi-bin/koha/admin/cities.pl?displayStart=10 But failed at having columns search work, even after fiddling with the deeepLink whitelist and columns in the URL. The last comment on this forum thread is also discouraging: https://datatables.net/forums/discussion/72488/link-to-prefiltered-datatable @Joubu if we could get: "We would prefer to not modify it but have a "Copy link" buttons on top of the table instead." for solution 3 that would be ideal, correct? i.e. not have the URL always present and changing but only have it be generated when clicking a "Copy link" button.
(In reply to Martin Renvoize (ashimema) from comment #19) > I'm quite disappointed that bug 14322 got attention when this one didn't :( > > Haveing a general solution would be so much better than the single table > solution proposed, and now pushed, in the other bug :( On the bright side most of the the changes to update itemsearch.tt were progress in the right direction because previously the form could not be filled from url parameters at all. For the 'Edit search' button to work the template needs to be able to fill the form, no matter how the static url piece is implemented. The advsearch.tt template has the same sort of logic in the template to fill the form from url parameters so that the 'Edit this search' button works. The big difference between the two is that the link on Advanced search actually refreshes the page and sends url parameters to fill the form. The button on item search does not refresh the page it just uses javascript to show the form that the user (and now the template via url) had previously filled in.
Patches rebased and pushed to remote branches. https://gitlab.com/joubu/Koha/-/commits/bug_27467_SOLUTION_1_keepConditions https://gitlab.com/joubu/Koha/-/commits/bug_27467_SOLUTION_2_deepLink https://gitlab.com/joubu/Koha/-/commits/bug_27467_SOLUTION_3_stateSave
I will give this one another go.
Moved to bug 33484. If you are interested in this feature please help the patches there moving. *** This bug has been marked as a duplicate of bug 33484 ***