bStateSave breaks bVisible

pluggy13

Hi,

I believe I have found a bug in your (otherwise excellent!) datatables plugin:

I have a table which should display 4-5 columns, depending on the data in the database. I am using the bVisible flag on one of the columns to hide or show the column accordingly when the page is reloaded.

Now when I also ads bStateSave:true to the table, load the page and then change my data so that the number of columns should change, then reload the page, the new value of bVisible is ignored. If I delete the cookie and then reload the page, everything works as expected (the number of columns changes).

In other words, it appears that the cookie set by the bStateSave:true option assumes that the table definition will not change. When it does change, the new settings are ignored. Instead, it appears that the old definition from the cookie is used. This is of course what you would want for the sorting options, but it seems to me that some other options (such as bVisible) should not be cached in the cookie.

Is this a bug or a feature I am misunderstanding?

Thanks,

Adrian

pluggy13

Bump... It's not urgent, but this does seem like a bug...

Thanks,

Adrian

allan

Hi Adrian,

This is an interesting one! The offending line of code which is causing the behaviour that you are seeing is:

[code]
if ( typeof oInit.saved_aoColumns != 'undefined' && oInit.saved_aoColumns.length == iLen )
[/code]
in the main initialisation. Removing the second half of that condition and then adding another one inside the loop to check that the array index you want to read, and the column, are available would do what you are looking for.

However, I hesitate to make this change as the majority of the time when the columns for the tables change the whole table has changed completely. Also, the column marking works on an index basis, so the situation could arise whereby the column the user marked as hidden before is now not longer hidden, but a different one is, after a reload.

So this is currently working as intended. The question is if that intended behaviour is correct or not...

Allan

pluggy13

Thanks, Alan! I think I'll stick to the vanilla version of dataTables to facilitate updates, but it's good to know why this happens.

--Adrian

allan

I've added a note to my to-do list to investigate what the right option to pick here is. I'll leave it as it stands for now, but I'll come back to it in future :-)

Allan

Foggier

Hi,

We just ran into this issue today and we really would like to use the state save. What's the status of this issue?

allan

It should be addressed in the latest releases. Can you link us to your example (or create one and post it) showing it not working please?

Allan

Eric

I just ran into this issue as well. A user can filter for Item Types for a project. The columns for these item types can vary (just slightly) based on project. If a user hides/shows columns in one "Table" that has, say, 10 columns, then switches to another "Table" for a different project that has 9 columns, then state saving is lost, even when I go back to the previous one.

Instead of index, could this be done based on class? Currently we can pass in a class name in aTargets. I was thinking if ColVis could use class name instead of index, and that be state saved, it could potentially solve the problem. Of course I didn't think this through a whole lot, was just the first idea that came to me.

j_syk

Bump to show interest about this issue.

My use case is that I use server side processing (via Django) to tell if a user is authenticated or not and then show an additional column.

So, if a user views the table as a generic user, then logs in to gain elevated permissions, the table still shows as before.

One easy/hack solution may just be to wire up a button to "hard refresh" the table and delete cookies in the process. Doesn't seem particularly user friendly, especially in the case where the user may not know that they are missing data.

Since my example is not quite as dynamic as the others, I can probably delete the datatable cookies at login/logout.

sebastienbarre

Chiming in as well as this just bit me. I'm using 1.9.2. Same way as there is a aaSortingFixed, maybe there is a need for a bVisibleFixed, so that the visibility of a column is really never changed.

Update: here is my fix. My rationale is that column visibility (in our application) can only be changed by the user if the ColVis plugin is in effect. Therefore, I use the fnStateLoadParams callback to see if the table is using ColVis. If it is not using it, then I empty the abVisCols variable in the state, so that the visibility of the columns is never changed. Something like that:

[code]
myloadStateParams = function (oSettings, oData) {
if (oSettings.sDom.indexOf('C') === -1) {
oData.abVisCols = [];
}
};

options = {
'iDisplayLength': 25,
'sPaginationType': 'full_numbers',
'bAutoWidth': false,
'bServerSide': false,
'fnStateLoadParams': myloadStateParams,
};
[/code]

allan

I've just put together an example of ColVis and state saving working together: http://live.datatables.net/atewig/edit#javascript,html . It appears to work as expected for me. Can anyone else confirm that this is the case for them as well, or otherwise?

Allan

dark_544

I ran into this issue as well. I think you forgot to hide a column in your example?
I modified your example and you see, this does'nt work:

http://live.datatables.net/atewig/4/edit#javascript,html,live

greets

dvnandover

Seeing the same issue as well. It worked when i delete the cookie prior to refreshing the table.

allan,
What is the fix, can i try it on my projet?