SearchPanes not working with DateRangeSearch

Schonhoff

Link to test case: https://toenjesportal.de/datatables/test-case (it is on my own side, because I use a little bit more scripts)
Debugger code (debug.datatables.net): N/A
Error messages shown: No matching records found
Description of problem:
Hello,

I'm currently using a date range filter and after I set it up with SearchPanes, I got something weird going on.

Steps for reproduction:
1.) Set a date in the max input field that is not or great than the current date. For example 27.10.2020
2.) Result: The table didn't change but the SearchPanes are empty.
3.) Set the date to the current date
4.) Result: SearchPanes are back again.

I would love some help to get this problem resolved.

sandy

Hi @Schonhoff,

If I am right, you are loading the SearchPanes options via ajax but want the SearchPanes processing to be done on the client side. Is that correct?

If so then the issue is because you are using searchPanes.cascadePanes and searchPanes.viewTotal. As this example (Loading options over ajax but using client side processing) states

It is worth noting that due to the requirements for users to provide accurate data for the SearchPanes options, neither searchPanes.cascadePanes or searchPanes.viewTotal are supported using this setup. While it is still possible to enable these options, it is not advised and may lead to unexpected behaviour.

I've just realised that this is not noted in the searchPanes.cascadePanes docs or the searchPanes.viewTotal docs, so I will get it added into there as well.

Thanks,
Sandy

sandy

Sorry I should also say that the solution is to either disable those options, or move to using Server Side processing.

Thanks,
Sandy

Schonhoff

Hello @Sandy,

first of all, thanks for the reply.

You are correct that I'm using AJAX to load the data but using client side processing for all the other stuff (because the Laravel Package for datatables has not implemented SearchPanes yet). So, this is a temporary solution that works really well in my case (almost).

The strange thing is, it works really fine without the max filter. It works with the min filter without any strange behavior.

Disabling both options temporary aren't loading the SearchPanes again after the result was filtered by the min/max filter. The SearchPanes showing all results but only one entry is shown in the table. Steps to reproduce this:

1.) Change my test-case with both option disabled
2.) Set min filter to '07.10.2020' and max filter to '09.10.2020'
3.) Result: Only one entry is shown in the datatable (Bielefeld) but all data is shown in the SearchPanes

After I did some testing with enabling one option after the other it seems like both options are dealing with the same behavior. What I don't understand is that single searching and applying the min filter is doing all good but the applying the max filter messes up the SearchPanes.

        $.fn.dataTable.ext.search.push(
            function( settings, searchData, index, rowData, counter ) {
                let max = moment(maxDateNode.val(), 'DD.MM.YYYY');
                let updated_at =  moment(rowData['updated_at']).startOf('day');

                return isNaN(max) || updated_at <= max;
            }
        );

If I just do this code as a search input instead the same unexpected behavior occured. If I do the opposite with the following code it works like a charm.

        $.fn.dataTable.ext.search.push(
            function( settings, searchData, index, rowData, counter ) {
                let min = moment(minDateNode.val(), 'DD.MM.YYYY');
                let updated_at =  moment(rowData['updated_at']).startOf('day');

                return isNaN(min) || min <= updated_at;
            }
        );

I really don't know what the difference between both code examples are (expect the obvious one to one time filter the min and on the other hand filter the max), but it looks really inconsistent to me. If you need to have both in separate test-cases for more help, I would set them up. Just let me know it.

Maybe you can take another look into it? Maybe it helps to find the location for the unexpected behavior?

Thanks a lot for your help already,
Michael

Schonhoff

Added both described cases into 2 test-cases:

Min filter:
https://toenjesportal.de/datatables/test-case-2

Max filter:
https://toenjesportal.de/datatables/test-case-3

Hope it helps

sandy

Hi @Schonhoff ,

Ah ha! I've seen this before I hope!

SearchPanes uses DataTables to display the options to the user. So, when you push onto the DataTables search function you are also adding that search to the panes tables. Including something like this in your search function

if (settings.nTable.id !== 'myTarget'){
  return true;
}

should allow you to apply your custom function to only the parent DataTable. When SearchPanes hits this it will just return true for all of the SearchPanes options.

Hope this helps,
Sandy

Schonhoff

Hello @Sandy,

it worked like a charm!

Maybe you wanna add this to your example here:
https://datatables.net/manual/plug-ins/search

I want to say thank you for your help and for such an amazing work you all do. Your Plugin helped me out so much to do my daily work. Thank you

Btw. I tried to add SearchPanes to a lot of other DataTables (~50) and all with client side loading at the moment. All doing good and all are configured with the viewTotal and cascadePanes option. The DataTables are all different configured with sometimes less sometimes a lot more columns, extensions and plugins. So maybe you don't need to mention the unexpected behavior anymore.

This comment here had the same problem I would guess:
https://datatables.net/forums/discussion/comment/171216
I just found it as I was searching for another way to do a date-ranged filter.

Thank you a lot and this thread can be closed if you want.
Michael

sandy

Good I am glad that it is working @Schonhoff .

I've filed a bug to add a note to the page that you have mentioned, hopefully that will stop others running into the same issue.

Thanks for the kind words, I'm glad that SearchPanes is helping you out

Thanks,
Sandy