Issues with table filters after latest update

I’ve been having issues with table filters since the latest release (7.27.1).

The filters seem spotty. Sometimes they work, sometimes they do nothing. This includes simple auto generated filters on a table and more complex filters that use subqueries and affect multiple conditions.

I have not been able to get consistent results. I created a button to deactivate all of the filters and query the model which works - but when I refresh the page the old filters are back. Similarly when I get a filter to work once, it won’t work the second or third time. Has anyone else had issues with this?

I updated to 7.27.4 and am still having filtering issues. It is mainly affecting my manual filters that are more complex. Any insight?

Alright, so I cloned my page and went wild with changing things trying to debug this. I found some tables would filter, others when you selected filter it did nothing.

The solution I found was to clone the model having an issue, and change the table to the newly cloned model. That’s it. This has worked on a couple different tables. I compared the XML, and I think the problem was from the auto-generated conditions that tables make.

It looks like when I cloned the model, the normally greyed out auto generated condition is now a normal condition that I could edit/change. Did something change in the last few updates regarding auto conditions? However, even after deleting the auto condition from the table and XML, the problem persisted. The only solution I found was to clone my model and change the table. 


Actually, there must be some deeper issue related to the model name. 

Here’s what’s happening:
Products: Filters don’t work
Products_clone: filters work when I change the table to this model

I swapped the names of the models - just the names.
Products_clone (Previously Products)Now works…
Products (Previously Products_clone): no longer works…

It seems there is something about the model name of Products that my page doesn’t like and is prohibiting filters from working correctly. There are a lot of other references to that name, I don’t know if that is the reason why. Any ideas?

Edit 2:

It seems there were a couple of problems. Knowing that the model name was the culprit, I traced the issue down to two things:

1) I had an action on the model to save if requried.
2) I had a snippet that fired when that tab was loaded that ended up saving the model.

After removing both of those, it works without having to clone the model in the first place. So my question is:

Does saving the model while it is trying to filter somehow override filters taking place? 

One thing that might be happening is when you’re changing the name of the models, Skuid has an issue where components can get confused about which model to look at. I.e., you have model “Products” and you clone it, creating a “Products1” named model. If you go to change the name of the model, and delete the 1, even if you immediately add _clone, components looking at the original model switch to looking at the new one. 

Otherwise, I have often found success recreating the component from scratch when it seems to be behaving oddly. 

Also worth noting that by removing my action to save after requery locks the search bar while someone is typing due to the UI only fields:…

Cloning the model ended up being a red herring as I traced the issue back to the model being saved while it was filtering. The names of the models were important because renaming the models did not rename the components like you mentioned - so the cloned model was not being saved as the action still had the original model name.

Just uncheck the remember last selected value on the filters that you have created…the skuid page keep the last filter value selected when it is refreshed

Hi Vaibhav,

Thanks for the suggestion, however this issue is unrelated to the remember last filter value. It turns out the save action being called when the model is requeried was interrupting/disabling the filters all together.