Dear,
We want to refresh a Freedom UI page from a business process.
This process is triggered when a field has been modified and will do some calculations.
After that, the page should be refreshed.
In Classic UI, there was an add-on in the Marketplace of it could be fixed with sending a message from a script task which was processed by a method in the javascript page.
Is this still an option in Freedom UI? Or is there another solution?
Kind regards,
Vincent
Like
Hello,
You can see how to do this for a Freedom UI page here
https://customerfx.com/article/receiving-server-side-messages-in-a-crea…
That article shows how to receive the message, the article links to another article that shows how to send the message from the process. As for refreshing the page once you get the message, see https://customerfx.com/article/refreshing-reloading-page-or-list-data-o…
Also, just to point out, this sort of thing won't be necessary in 8.0.7, which is due out soon. There will be a built in way where you can set an option in the object for it to auto refresh called "Enable live data update". Checking this will handle the sending of the message and refreshing any UI bound to the object automatically when the object is modified in processes etc.
Ryan
Solem Khn,
Yes, for Freedom UI pages only, the Live Update works great.
Ryan
Solem Khn,
Hi. I had issues with this initially. Make sure that you set Enable Live Update on the object within 'Custom' package. I initially just did it on object within my Package and it did not work
Rob Watson,
without departing too much from the original thread - in case changes from your development packages are not visible/applied, there's probably an issue with the dependencies of the packages you are working in.
Say you have Package XY that depends only on some Core Packages. If you change the configuration of the "Account" object in Package XY, those changes should be applied in the configuration afterwards. However, if another Package Z sits "lower" in the dependency tree and also contains a replacing schema for "Account," Package Z will always win in case of a configuration conflict. So if XY sets the live data update attribute to true and Z sets it to false, Z's value takes precedence.
The same applies to other configuration schemas that use replacing logic, such as Freedom UI Pages. This replacing logic is what makes it possible to build customizations ON TOP of functionality from other already existing packages on the Creatio platform.
Otherwise you wouldn't be able to modify pre-existing schemas like the default Account Page that ships out of the box.
Basically, for any new customizations or development, you want your package to be just low enough in the dependency tree so it can overrule the pre-existing configuration where it is needed, without creating unnecessary dependencies to all unrelated packages.
Best, David