In a previous article I showed how to prevent navigating back, or closing a Classic UI page when it is saved in Creatio. The previous method would pass a config object to the save method with an isSilent property (if isSilent is true it would prevent the form from closing). For a Freedom UI page, that previous method does not work, however, there is an easy equivalent. You must handle the save on the page by adding a crt.SaveRecordRequest and then can set a preventCardClose property on the request to prevent the form from closing.
{
request: "crt.SaveRecordRequest",
handler: async (request, next) => {
request.preventCardClose = true;
return next.handle(request);
}
}
Note, this does work as expected, but does produce some odd results on some pages. For example, the Case page shows several things once the CreatedOn is populated and it appears that the data isn’t reloaded after the save. The code above will prevent the page from closing, but without the data being reloaded (and since many elements on the page are shown using the population of the CreatedOn) you might, in some cases, also have to do a reload in addition to this.
Hi Ryan,
If your page is in CardState = “add”, and you’re reloading the page after preventCardClose, then the url remains with /add format rather than /edit/guid, wich seems to be a Creatio issue IMO.
You can also specify this param directly on the button click action, in case you want some save buttons to behave this way but not all save actions:
"clicked": { "request": "crt.SaveRecordRequest", "params": { "preventCardClose": true } }Hi Ryan,
thank you for the article, it was helpful.
I have a question regarding a slightly different scenario.
In my case, the Case page is opened in edit mode from a business process (Open Edit Page). After saving the record, the page is automatically closed, but I need to stay on the same page after save.
I tried using preventCardClose as described in the article, but it seems that this approach does not work when the page is opened from a business process.
I added the following handler:
{ request: "crt.SaveRecordRequest", handler: async (request, next) => { request.preventCardClose = true; const result = await next?.handle(request); if (!result || result.error) { return result; } return result; } }However, the page is still closing after save.
Is there a recommended approach or alternative solution for this scenario when the page is opened via a business process?
I’ve not checked, but it could be that the logic has changed slightly in recent versions. In current versions of Creatio, the save button (any button with a Save data action) has a property to indicate whether to close the page or not. You can just set it there (it’s possible it has to be set prior to the request firing now?)
It’s also possible that it gets ignored for pages opened via processes – there are a few things that work differently for pages opened that way.
I tried an alternative workaround on my side.
I added a boolean flag on the Case record to indicate that the page was opened via a business process. Then, in the SaveRecordRequest handler, I check this flag and explicitly trigger an UpdateRecordRequest for the same record.
const isCreatedInProcess = await request.$context.PDS_QicIsCreatedInProcess;
if (isCreatedInProcess) {
const recordId = await request.$context.Id;
const handlerChain = sdk.HandlerChainService.instance;
await handlerChain.process({
type: “crt.UpdateRecordRequest”,
entityName: “Case”,
$context: request.$context,
recordId: recordId
});
}
As a result, after saving, the record remains opened in edit mode, which is the expected behavior.
During testing this works correctly in most cases.
However, occasionally an error appears in the browser console, and in those cases the Save button is no longer visible when the page is opened in edit mode via the business process.
message: Uncaught TypeError: Cannot read properties of undefined (reading ‘name’)
stack: TypeError: Cannot read properties of undefined (reading ‘name’)
So while this workaround mostly works, it does not seem to be fully stable.
I wanted to check if this approach is valid in general, or if there is a more correct way to handle this scenario for pages opened from processes.