I have the following model structure:
Order Item (Master-Detail Order)
Order Ship Periods (Lookup to Order Item)
I have built a Skuid page that displays the Order object and contains a table of Order Items. There is a table row action on Order Item that displays a pop-up.
When the popup displays, all of the information for the item is accurate and reflects the proper row from the table that was selected.
I have placed a table on the pop-up that is intended on displaying the Order Ship Periods, however this table displays zero rows and indicates there is no data.
I’ve inspected the models (skuid.model.getmodel(‘OrderShipPeriods’), etc.) and it does contain elements in the data property. if I try to “add new” row to this table, the count of elements in data property increase but still no fields are displayed.
Read though the forums and it appears that this should work but am unable to determine what I might be doing incorrectly and can’t find a sample that contains 3 or more layered objects with 2 (or more) of those layers in a popup.
Can anyone provide any insight or point me to a sample to reference?
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.
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).
(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
Makes sense on both fronts. Thanks again for your prompt replies and providing the context, greatly appreciated!