Skip to main content

Scenario:


  1. We use a popup with a table in it and a search box on it (in this example the Users object)

  2. Open the popup and search for a name (this works as expected)

  3. Close the popup

  4. Open the popup. The problem is that the search criteria seems to still be active. However there is nothing to delete in the search box. So we are stuck with nowhere to go until we refresh the entire page!

Sample XML:


<skuidpage showsidebar="false" showheader="false">
<models>
<model id="Users" limit="20" query="true" createrowifnonefound="false" sobject="User">
<fields>
<field id="Name"/>
</fields>
<conditions/>
</model>
</models>
<components>
<pagetitle model="Users">
<maintitle>
<template>{{Name}}</template>
</maintitle>
<subtitle>
<template>{{Model.label}}</template>
</subtitle>
<actions>
<action type="popup" label="Test Popup" window="self">
<popup title="New Popup" width="800">
<components>
<skootable showconditions="true" showsavecancel="true" searchmethod="server" searchbox="true" showexportbuttons="false" pagesize="10" createrecords="true" model="Users" buttonposition="" mode="read">
<fields>
<field id="Name"/>
</fields>
<rowactions>
<action type="edit"/>
<action type="delete"/>
</rowactions>
<massactions usefirstitemasdefault="true">
<action type="massupdate"/>
<action type="massdelete"/>
</massactions>
<views>
<view type="standard"/>
</views>
</skootable>
</components>
</popup>
</action>
</actions>
</pagetitle>
</components>
<resources>
<labels/>
<javascript/>
<css/>
</resources>
</skuidpage>


Looks like switching to client side search clears the search everytime the popup is initated. Not a fullt robust mechanism, but should get me out of the current bind.


Glad you were able to find a workable solution for your pop-ups!

Zach wrote about the client vs. server-side searches in a different post (What fields does a search box search?) that might be of interest to you: https://community.skuid.com/t/what-fields-does-the-search-box-search 

Zach’s helpful response is the last bit of the post.

-Josh


Thanks Josh. This works in this instance, however, this is not a robust solution if we have lots of data rows. I assume you are acknowledging the bug and putting it on the roadmap for resolution? Thanks.


Hi Ant,

Confirmed, this is a bug / user-experience inconsistency with Table server-side search. As you have expressed, the issue is that Search Conditions generated from search text entered in the Table’s search box remain applied to the Model even after you close the Popup, but when you open the popup back up, the Table’s search box does not reflect that there is search text applied.

Our solution for resolving this will be to to check whether search criteria has been applied to the Model, and attempt to use this to recreate the search text for the Table, so that when you open the Popup back up again, the previously-entered search text will still be applied.

We’ll update this thread when the issue is resolved.

Regards,

Zach


Here’s a fix for this that should cover most if not all cases:


when the popup opens loop through the model conditions and deactivate all conditions that are not “inactive” and ARE “originalInactive”. this will deactive all conditions besides for the search box. To deactivate the search box you can deactivate based on a few criteria on the condition:


  1. field is null

  2. subconditions.length > 0

  3. name contains "searchbox"

example:

var reload = false;

var model = skuid.$M(“model-name”);

var conditions = model.conditions;

for (var i = 0; i < conditions.length; i++)

{

var condition = conditionsni];

if (!condition.inactive && condition.originalInactive)

{

model.deactivateCondition(condition);

reload = true;

}

else if (!condition.inactive && !condition.originalInactive)

{

if (condition.field == null && condition.subConditions.length > 0 && condition.name.indexOf(“_searchbox”) != -1)

{

model.deactivateCondition(condition);

reload = true;

}

}

}

if (reload)

model.updateData();


We were having this same problem and Mordechai’s solution worked perfectly. Thanks!


Zach Was this bug considered resolved on your side? Like Craig below I took Mordechai’s solution and got it to work for our use case, but I’m just curious if this was every resolved since I can’t find mention of it in the community. Thanks, Jeff


Reply