Related List of child record not displaying in popup

1. Ensure that the lookup field on the OrderShipPeriods object that points to OrderItem (e.g. Order_Item__c) is in your OrderShipPeriods Model. This is essential.

2. Go into the XML for your page, find the inside of your 's child node, and there should be a node looking something like this:

Replace the part in bold with

where you would replace Order_Item__c with whatever the Lookup Field to your OrderItem object is on your OrderShipPeriod object.

Basically what this is doing is telling the Table which OrderShipPeriod records, out of all of the records in the OrderShipPeriods Model, to show in the Table, by referring to the Popup’s “context” OrderItem Row — that is, the Row whose Row Action you clicked on.

This allows you to retrieve all OrderShipPeriod Items that are grandchildren of the Order, and then the Table in your popup on OrderShipPeriods, while linked to the OrderShipPeriods Model, will be able to apply the “data conditions” specified in the XML to whittle down the list to just those OrderShipPeriods related to the context OrderItem.

This is an advanced feature that is currently hidden from the UI to reduce complexity, but which is “automatically” applied behind the scenes when creating new popup row actions for the most common use cases. The trick for the “autocreation” to get it “right” is to have first added a Lookup/MD field that links your grandchild to child record — e.g. the Order_Item__c lookup field — to your grandchild model, THEN create the Row Action on your child model, and drag in a Table on the grandchild Model. If these steps are done, then Skuid would have autocreated a data condition with field=“Order_Item__c”.

Zach - Thank you so much for the quick reply and solution!  Once I modified the condition element everything worked as expected.  Also confirmed (on a new skuid page) that by setting up all the models first and then creating the popup table that skuid established the condition element automatically as you describe.

Couple of questions:

1) What does the attribute “autocreated” influence?
2) As a best practice, is it recommended to use the models that drive the main page within the popup or is it better to have secondary models of the same type that are used on the popup (e.g. Order/OrderItem/OrderItemShipPeriod and then OrderItemPopup/OrderShipPeriodPopup) passing in the id as a url parameter?  Would the best practice differ based on whether or not we’re editing an existing Order vs. creating a new one (we’re going to follow same pop-up concept with edit & new).

Thanks again!

(1) If you remove the autocreated attribute, then Skuid will not automatically update a data if, say, you change the Model of the Table to a different Model, in which case, if you’re letting Skuid have the responsibility of creating/modifying these conditions, Skuid would examine the new Model, look for a relationship field linking this Model to the context Model, and use that field to set the field=“” attribute. But if you’re comfortable with managing these data conditions yourself, then remove this attribute and Skuid will not try to mess with anything anymore
(2) I think that it depends on what your Main page is doing. If your main page is a Tab page, e.g. an Orders tab, and you wanted to have the ability to see all related child / grandchild records of each Order in the table in a Row Action popup, then we recommend using Page Includes inside the Row Action popup and passing in the Order Id as a URL parameter. The rationale here is that this is easier to “declaratively” manage — the Page Include approach handles requerying for child / grandchild records related to the context parent record, and then rebuilding the Table on the child / grandchild records. You could manage all this from JavaScript, and avoid the Page Include, but then you’d lose the benefits of managing it all “declaratively”. If you main page is a Detail / Edit / New page, then you can probably take this data approach. In the New page scenario, definitely. In the Detail / Edit page scenario, just consider that if you want ALL related child and grandchild records for the parent to be visible, you’ll have to query for them, e.g. you’ll have to REMOVE the “Max # of Records / Limit” for the child/grandchild Models to guarantee that you always retrieve all child/grandchild records.

Makes sense on both fronts. Thanks again for your prompt replies and providing the context, greatly appreciated!