I have a model on a child object in a master-detail relationship. I display the child records in a table in a drawer under the master record(s).
The child table has a New Row global action. The new, child row has a dependency on a field value from the master record. The child model includes the master reference and ‘Id’ fields, as well as the custom field (call it CCM__c).
When I load the page and go directly to the drawer and click the New Row button I can see that the master CCM field was accessed successfully. I can also go to the browser console and run skuid.$M(“ChildModel”).data[0].Master__r.CCM__c and obtain the value of the field in the master record.
But, if I click another tab in the page, and another drawer for a different model, then come back to the New Row button described before, the master field is missing from the child model. On the browser console, skuid.$M(“ChildModel”).data[0].Master__r.CCM__c returns undefined. Exploring the model shows that the master field is no longer part of the master reference object. Its name and Id and certain other fields are still there however.
To the best of my ability, I have checked that nothing in the other tab and drawer is referencing the model that gets corrupted. The other tab and drawer are using the same objects but not the same models as the drawer and table where the corruption occurs. I have checked activate-and-set-condition actions, save and cancel actions, requeries, and event-based actions on the models themselves, but nothing seems to access the model that goes awry. What else might be the culprit?
skuid version 9.5.4
Why / how would a field disappear from a model?
+9
+20Hmmm … “ChildModel”. Are you using that as a generic name here for this post, or is that the name of the model? If the latter, I recommend naming something relevant to the use case. ie. Case_Tasks.
+9Do you mean specifically the Remove All Rows and/or Remove Row(s) actions? Because the XML shows none in the page that affect either the child model or its parent.
I’m also wondering how that would affect the structure of the model. (Although, I’ve noticed that skuid.$M(“ChildModel”).fields does not change when the data does.)
+20One more thing. When setting the drawer action to query the child records, be sure to select the get more option.
+9Yes. I did check that. I’m always a little unclear about the Context property, but I think that is correct too.
+9Pretty complex. About 5100 lines of XML, and all custom objects.
FWIW, I’ve worked around it, so it’s not a show-stopper. I’m more wondering if there is something else to scour the xml for. (Like Tab actions, which weren’t an obvious thought, but those are clean anyway.) Or hints about deep internals, maybe, like whether different models on the same object share data spaces somehow allowing a field in one to get clobbered by its absence in another.
+10- Nintex Employee
Hi Mike, I’ glad to see that Pat Vachon has been engaging with you. Can you tell us which Skuid release you’re working with?
+10- Nintex Employee
Since you’ve looked at the models via the console, do you get the sense that setting a drawer context on a second drawer is affecting/removing the context of the first? Or that navigating to a different tab may be affecting the row context? I’m glad to see you’ve said that this isn’t a show-stopper, but if there’s a behavior in Skuid that needs to be addressed, I’d like to try and zone in on it.
+9
I don’t know if this image will be legible enough to shed any light, but I’ll try.
-
The left column is the data node of the child model. The 4th line down is the parent reference, CCM_Referral_Placement__r; I’ve expanded that node.The first field from the parent is CCM_RTX__c, the field whose value (“OTX”) I am interested in. It is accessible here, before I click the suspect tab and drawer.
-
The middle column is the same model, same data node, retrieved after the side trip to the other tab. Note that the parent node has significantly fewer fields than the left column, and specifically, CCM_RTX__c is missing.
-
I tried something different than previously discussed: I actually created the new row that this functionality is all about. Then I started creating a second row and looked at the model again. That is the third column, and notice there are even fewer fields from the parent - but my field of interest is present.
For reference, here is the field list from the model:
The actual model shown in the console doesn’t match. It doesn’t seem to include null/empty valued fields (like End_Date__c and Number_of_Days__c), which makes some sense. But what determines the fields included from the master record, and why does it vary so much? The only activity between the center column and the right column was a Save of the model and a Create New Row.
+20Truly doesn’t make sense at all. Something screwy going on. I can’t say it’s something that could be fixed via this community post. I think this would require screen sharing.
+9This may have been resolved in 9.5.5, 9.5.6, or 9.5.7. We made the jump from 9.5.4 to 9.5.7 yesterday. Today I came up with an idea to try, but could not reproduce the error before making my change. I’d love to re-check in our 9.5.4 production org but can’t easily set up the test.
+10- Nintex Employee
Thank you for the update and detailed information, Mike. I’ve looked through the release notes for 9.5.5, 9.5.6, and 9.5.7, and don’t see any fixes listed there that would obviously apply in your scenario. Sometimes, it happens that other perhaps lower-level product updates can touch upon and address issues like this obliquely. I’m glad to see that the issue appears resolved for you, but if you find any further trouble along these lines, let us know.
+9The only thing seemingly even close was in 9.5.5: [SKUID-3362] - Unable to add Reference Fields on OData Model. I will watch, however, if I build something similar in the future.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.