Which is related to what I’m trying to do. Right now I’m querying
the opportunity and subquerying the notes of the opportunity. However, I want
to allow the user filter the subqueried notes that are shown. Here’s how I’m trying to
solve that.

Create an opportunity model

As a model field in the opportunity model, subquery the notes object

Add a condition to the subquery. Condition is ‘field from
another model.’ (from model in the next step)

Create a Notes model and add filter to the page so the user
can filter on the notes model.

Add on model action to the Notes model so that when Notes is
requeried (i.e. filtered), the opportunity is requeried and the subqueried
noted recalculates its condition.

The problem is that for some reason when the opportunity is
requeried, the model merge values don’t update. They remain whatever they were
on page load. This wouldn't be such an issue but a side problem is that subqueried field conditions aren't available through javascript as regular condition objects meaning this can't be solved through javascript.

Steps I took to verify my process:

Add model action on requery of notes and opportunity model
that blocks the UI and displays “{{modelname}} successfully requeried” to confirm each
model is being queried in the correct order. Result is that querying order is happening as expected.

Before and after filtering the Notes model type in console

skuid.model.getModel('Notes').getRows()

and verifiy
that their returned results are different. Result: They are different as expected.

Check
Opportunity SOQL before and after filtering using

skuid.model.getModel('Opportunities').getSOQL()

.Result is that the SOQL is unchanged – this is
the problem.

Create Aggregate note model that counts number of notes with
0 in it. – this correctly reflects the number of notes with 0 in it.

Here’s a sample page. When you press "Remove notes that contain 0 in title” it filters out notes with a title that contain the text “0” from the note model, and requeries the opportunity which has a subquery field with a condition depending on the notes model.

So before pressing the button I expect to see this. Which is
what I’m seeing. (image)

After I press the button I expected not so see notes with "0" in the title. But they still show up. The highlighted records are the ones I expect not to show up.

To test this, paste the xml below into a new page and create some note records related to the opportunity that contain anything. Then create some note records related to the opportunity that contain "0” in the title. It should
remove the notes containing "0" in the title after pressing “Remove notes that contain 0 in title”, but it doesn’t.

But even when querying together it doesn't work. I tried both in the action framework and also in the chrome developer console to query simultaneously and the conditions in the subquery aren't respected.

Yes. I must have made a mistake. The update is working when I query them together, thanks a bunch! Now I'm working on a way to use after model events to requery the dependent model while avoiding recursion...

Thanks for Pat for the information on needing to query both models simultaneously.

For anyone that has run into this specific situation, here's how I solved it:

Create a UI only checkbox called 'secondQueryHasNotRun'

On load, subscribe to all three condition events ('condition.valueChanged','condition.deactivated','condition.activated',) and add a callback function that updates the 'secondQueryHasNotRun' field to true.

In the filter model, add an after requery action. In the action, add branch logic that checks to see if 'secondQueryHasNotRun' is true. If it is true, update the dependent models (including the model that initiated the query) and change the value of 'secondQueryHasNotRun' to false.

Now each time you change a condition and update the model, the filtering model and dependent model will be updated in the same action, allowing for the subquerying condition to work, and avoiding recursion.

Warnings:

You may want to do some additional filtering on your subscription callbacks if you don't want every change of every condition on every model to update the UI only field

This feature is still somewhat of a hack since the initiating model (filter model) is still queried an additional time unnecessarily.