8.1.3 or 8.1.2 breaks page param setting in the crt.HandleViewModelInitRequest handler
Just a quick PSA - either 8.1.2 or 8.1.3 breaks the ability we had before of being able to set Page Parameter values in the crt.HandleViewModelInitRequest request handler, since in the newer versions it appears the value is reset back to the default (similar to how fields based over table columns are) at some time after the init handler runs. This is quite frustrating, as it's reducing the number of options we have for setting values in the code where required (which it still often is with the current options for no code development).
A workaround that Ryan Farley has previous mentioned using for setting field values by using a javascript timeout can be used for this too, e.g.
setTimeout(() => {request.$context.TextPageParameter = "Test value";}, 300);Like
Hello, Harvey
I also had such an isuue but I resolved it by calling parameter initialization after let result = await next?.handle(request); And then in the end return result;
Andrii Orlenko,
Mine was already being initialised after awaiting the result of handling the request, so it might be that sometimes this takes long enough to be ok but not always (so would introduce a race condition).
Anhelina,
Thank you.
Just an FYI, I've been reporting this since 8.0.10 (see #SR-01234445). I was told this would be resolved in "the nearest releases (8.1.1-8.1.2)", however, it's still an issue in 8.1.3 without a commitment from Creatio on a specific timeframe for a resolution. This is a pretty huge pain point so it's disappointing that it's still a problem. I do love Freedom UI (and I'll take it any day over classic!) but there's been many instances of my code breaking along the way with new versions and it sometimes seems less urgent for fixes for issues that go beyond the "no code" customizations.
Ryan
Ryan Farley,
I checked that case before replying to Harvey and asked the responsible team to raise the priority for this task. I apologize for the delay and hope to see the fix soon.
Meanwhile, they shared one more workaround, which is better to use with parameters:
add the handler on parameter changing and rewrite it when the default value has appeared:
Anhelina,
Yes, this approach does work if all you need when the form is initialized is to work with a single value on the page. However, that is often not the case and each property initialization can happen at slightly different times, so referencing other attributes in this same handler might not work, depending on the timing of the various attributes being loaded/initialized. Adding a separate handler for each attribute you need to work with can get messy quick.
Ryan
What I think would be nice/match the existing patterns would be to have some new request handler that does the setting of default values on the page, something like "crt.HandleAttributeInitRequest", which would perform the OOTB platform's setting of these values in the next?.handle(request) and then after awaiting the result of that a developer could set their own defaults for fields they need to, which wouldn't be overwritten (since the defaults had already been set).
It would also be nice to be able to "silently" set these default values (like you could in Classic UI) so that setting values in that request handler wouldn't cause the "are you sure" dialog to appear if a user closes the page without actually modifying the data themselves. Actually it would be nice to be able to do that generally from within request handler code.
Hi, is there any update on the matter?
Still when you're trying to read the attributes on crt.HandleViewModelInitRequest the attributes aren't initialized and are all undefined