I’ve experienced the same behavior. As a work around, I change the condition to single (or multiple) specified value(s), and then use Activate and Set before the query. Not sure if that will work in your use case.
I wish I could set a dynamic set of multiple values for the condition, but alas I the option is not possible.
I’m pretty sure that you can pass your values into a string with semicolons between, and it will work. Something like this:
conditionValue = ‘value1;value2;value3;’
The problem is that these need to be based on what is in another model. These are to be the Opp Id’s.
I don’t want to say to the client that I need to charge additional time for something I think should work. I hate putting together a work around at the clients expense.
Yep. I’m with you there.
Not that I have clients… I’m just working on the same massive implementation for the non-profit I work for.
I’m hoping we can move to having Skuid take care of this for you, or have some way of preventing the infinite loop.
My beef is that the Opportunity model has the ID’s but there aren’t being used dynamically.
My beef is that Opportunity__c is a value I’m checking to see matches the ID field in the opps model. There is no need to go to the server for these. Why can’t we set the condition and evaluate based on what’s in the opps model when querying the related model? Why is it that querying the models together or separately makes a difference? It’s as if the list of opp ID’s on the related table is only updated on page load and when the two models are queried together.
Can you convert this to an idea?
Good news! it’s already fixed in the next major release.
Sweet!!! Really really looking forward to that. This is my one big gripe on the model conditions.