Here’s the situation:
I have a detail page that has a page include on it which includes additional information about that record. The reason for this is the page include has custom fields on the object that are not part of the main managed package. The page include allows the use of the same main page and ability to pull custom fields not on the main detail page.
When I go to clone the main page (URL param clone=1), the main page info is cloned but the page include’s fields are not cloned.
Here’s my objective:
I would like to use the clone=1 parameter to create a new cloned record that includes cloning of the custom fields in the page include.
What I’ve tried:
I’ve used JavaScript on the main page to modify the string query of the page include to have the “clone=1” parameter when the main page has that parameter added. I can also save the page include model using JS at the same time I am saving the main page’s model. This creates two cloned records. One includes changes to the main page but no page include data, and the other does the opposite. I suspect even though the objects are the same, because the model names are different cloning is creating two different records.
Is there anyway to clone the page include data onto the same record that the main detail page creates on clone?
Create two page includes. One with the clone parameter using mustache from main page. Another without. Conditionally render based on URL parameter being there.
I’m not sure I understand if/how that fixes the issue of cloning both the main page and the page include at the same time. I’m able to get the page include updated with the clone parameter, but saving still creates two new records
Oh … yeah … not sure you could do this. Best case would be to “merge” the record changes on the Save button. A snippet to move the changes onto the main page model prior to save followed by a page refresh.
Yeah that’s what my plan B is, was hoping to get around it with the clone inside the page include.
This is what my code looks like to update the page include query string dynamically since I did not find this documented. Not sure if messing with the $C properties is technically supported or encouraged though.
<br>skuid.$C('pageIncludeName').querystring = "id={{$Param.id}}&clone=1";<br>$.when(skuid.$C('pageIncludeName').load())
Could you clone and save your main page model, then pass that new cloned Id into your page include to add the additional fields? I may not be understanding your use case. Seems like you should only be cloning once or you will end up with two clones.
Its a matter of cloning the fields in the page include along with the values from the main page. The main page model does not have the same fields loaded, so I am not able to clone those values from the main page and just adjust the page include parameter.
The specific use case is a customer has custom fields on an object from our managed package. They want those fields to be displayed on the object’s detail page. If they customize the Skuid page, it gets reset when we push a new version of the package. What we have decided to do, is include their custom fields in a page include, that way when we push a new version, it is very quick to add their custom fields back onto the page with the page include.
When they try to clone from our parent page, it is not going to see their custom fields on their model in the page include. I think some JS to update the parent page fields after cloning is going to be our best bet.
Tough… could you build their custom fields into your installed package pages and set rendering on them based on profile name, then have the customer rename their profiles something unique that would only apply to them? Like instead of a profile “Employee” name the Profile “XYZCompanyEmployee”. Then only their users would see the extra fields and it would be built right into your installed package pages and objects so you wouldn’t have to worry about upgrade compatibility.
That would cause an error for users that don’t have those fields on their objects when the page loads since the SOQL will try to retrieve those fields regardless of if they are rendered. Also customizing the managed package to individual customer’s needs isn’t feasible with scaling.
Unfortunately I don’t believe there is a “clean” way of handling customization to pages in a managed package. The page include has been the best solution we’ve found so far. Certainly open to other ideas though.
