Here’s a complex one. Have at it, friends!
Interaction Object is a child of Case Object is a child of Patient Object. There is a lookup relationship between Appointment Object and Interaction Object.
I have a Scheduling Page with a calendar component which has the AppointmentModel as its event source. On calendar click I load a custom popup, and the user fills in data into the AppointmentModel. Then, the user can click a button in the page title component on the popup to save the data and open a second popup, which has a page include with the following:
I have a table on PatientModel, with a drawer containing a table on the CaseModel, with another drawer containing a table on the InteractionModel.
I have a global action button on the PatientModel table that adds a new row to PatientModel with default values from an AppointmentModel.
I have a global action button on the CaseModel table that adds a new row to the CaseModel with default values from an AppointmentModel.
I have a row action on the CaseModel table that adds a new row to the InteractionsModel with default values from an AppointmentModel.
I have an action set up in the PatientModel such that when a row is added, a new row is created in a CaseModel with values from the AppointmentModel.
I have an action set up in the CaseModel such that when a row is added, a new row is created in the InteractionModel with values from the AppointmentModel.
If I run the page-include as a stand-alone page, this works great. However, when I run it through the Scheduling Page through the page include, not so much.
PROBLEM: When I use any Create New Row action, it adds a number of rows to the child object equal to the number of times that I’ve opened the popup since load of the parent page.
For example:
I create an appointment, save and open the Assign Appointment popup with a button. There is nothing in the PatientModel (and therefore nothing in its child or grandchild).
I run the New Patient action, and get this result:
As expected, a row is added to the PatientModel with values from the AppointmentModel, which triggers a row being added to the CaseModel, which triggers a row being added to the InteractionModel. Perfect.
Now, if I close the popup, reopen it (doesn’t make a difference if it’s the same context row on AppointmentModel, or a different one), and run the same action a second time, here is what I get:
Two rows in CaseModel, and in each of them, two rows in InteractionsModel (4 total).
If I close it and open it again, I can create three identical rows in the CaseModel, each with three identical rows in the InteractionsModel, all with a single click!
Strange, right?
Here’s the basic question:
Why would having a page include popup from a calendar popup cause duplication of the ''create new row" action once for every time the popup has been opened since pageload?
Haven’t read over the whole post, just the question at the end. :S
Do you have any model names that are the same across your pages?
Thanks for the quick review, Pat. All models have unique names.
Lengthy situations like this I get lost. Can you explain by video?
Ok, here is a shot.
I believe that the problem is that the three models from the include page are still in memory (from the first time you open the scheduling popup and add a patient), and then when you open a second scheduling popup and add a patient - a new patient is being added, but a case record is getting created for both rows and so on.
I believe the solution will be to start your action sequence that opens that second popup with a cancel model action. This will clear out existing rows and only load one row.
I can’t really explain it, but I think that is whats happening.
PS. Pat; I love the TL:DR admission…
Rob,
I think you’re right. I’m having trouble implementing the solution.
First question: should I be running a “cancel model changes” action or a “empty model data” action?
The models in the page include are not in the primary page, so I can’t empty those models in the action sequence that opens the second popup. Is there a way I can run a ‘pre-load’ action for that second popup?
Alternatively, I could add an ‘empty model data’ action to the beginning of every ‘create new row’ action sequence. I’m thinking this would have undesirable results, however. For instance, in the situation where the patient exists and I am creating a new case for the patient, I don’t want to empty the model of the data from the previous case. If I had to do that, I could requery again later, I suppose.
What do you think is my best course?
I also just realized that perhaps I’m misunderstanding you. Which models are you suggesting that I cancel/empty before opening the second popup?
Just had another thought. If the models from the page include are stored in memory on the main page, could I add an Empty Model Data action to the sequence that opens the second popup, and edit the xml to include the names of the models in the page include? I can’t select those models in the ui, but would it work if I trick the xml? I’ll give it a go.
Arg… that one didn’t work. Any other thoughts?
What is this empty model data action that you speak of? Is this a new action available in the super bank?
not sure if it’s new, but here it is. We are running superbank. 
I added the following “Empty Model Data” action at the beginning of my “Add Patient” action sequence. I still get the same results… duplication of child fields once for each time I’ve opened the popup.
That is new for sure. Much needed new action though. Awesome.
Apparently my screen recording system didn’t actually start recording until part way through. So you’re jumping into the middle, but I think this get’s the main idea across.
Does refreshing the page reset the accumulation of drawer case and interaction records?
Yes!
Interesting. Are the actions that empty those models performed in an action on the page in which the models reside?
I followed your question, the answer is yes.
I attempted to add a “empty model data” action at the beginning of the sequence that adds a new patient (which triggers a new case, which triggers a new interaction). It didn’t make a difference.
This was marked as Solved, but I apparently missed the solution. I’m still having the same problem. Help?
Sorry about that. I’ll dig into this question this afternoon…
Thanks, Rob. Looking forward to it. Would it be helpful if I gave you access?
Yes Jim. I was trying to recreate the situation and that is just taking too much time. Here are instructions on giving us login rights. Then send an email to Support@skuidify.com with your ORG id and the name of the pages…
Email sent. Thanks!
Closing the loop… we actually did solve this. Had to use a different methodology by eliminating the page include and creating everything on the parent page.
Also had to make sure that models on new parent objects were saved (got a real sfdc id) before creating/saving rows in models on their child objects.
Reply
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.