Does the source model start with rows and then after page load? I’ve seen instances where the model activation only works when both models are queried at the same time.

So it’s functioning practically, but if you try skuid.$M(‘ModelName’).conditionsi0].inactive in the console, the value is “false”, and it’s appearing as active in a related filterset

Here’s a test page, if you make the Account filter not pull any accounts, you’ll get Contacts, the condition is obviously off, but it doesn’t register as off in the console, and you’ll see the Toggle filter should isn’t activated even though it should be.

I’ve tried loading on page load or not for both models and it doesn’t seem to help. 

Jack, I looked at this with Carl, and I agree that this is either a bug or weird behavior that needs some explanation. Essentially, you’re correct - a condition with value of FFAM, set to filterable default on, with the rule to de-activate if no rows in source model, will run the correct query on page load, but the condition state is still technically active. We’ve reproduced it and are writing up a bug report. We’ll post back here if we find out anything more.

er … uh … works for me. It does deactivate but fails to indicate such in the model.

Do you mean “Deactivate” or “Abort Query”?

Hey all… There was a gathering of folks here on floor 6 of Skuid HQ last Friday about this. 

Think of it like the Council of Elrond except there were not elves… Just Matt Brown and some solution engineers… some look like elves, others look like dwarves, though. 

I’ll pass on what we learned after Matt and I kicked it around earlier last Friday. 

The Inactive Property on the condition refers to the condition state


So… if the condition state is set to “Always On” or “Filterable Default On”, this merge syntax in a template component {{$Model.Contact.conditions.0.inactive}} will show up as “false”. 

This value remains the same, without regard to the setting of “Deactivate this Condition” in the “If no  row in Source model, then…” property. 

One solution engineer here at Skuid said, the choice should actually read something like “DISREGARD this Condition” as opposed to “Deactivate this Condition”. 

That is what I am seeing in the post that Pat V made in this thread.   The SOQL query is just disregarding the where clause.  BUT the condition is still technically active. 

In other words, it’s actually not a “bug”.  The behavior here is doing what’s expected by the devs at this time… but the terms that are used here could be less confusing. 

This thread is reminding me of a scene in the “The Court Jester” movie. 

Hopefully my post helps add clarity.  Fingers crossed…  

I will take the ring.

So… I can see an issue with this. There are times this value, or some other value, needs to indicate whether a condition is active or not. Those times are when a snippet of code evaluates whether the condition is active or not.