I have run into an issue uplifting configurators from Classic to Kinetic. We have a number of fields that are only applicable if certain other fields are selected/set to specific values. If the ‘child’ fields are available they are required entries.
In classic this worked fine and in the uplifted version the dynamic read-only works properly as well but whether they are read only or not, because they are required fields kinetic throws an error. In classic you used to be able to do this and the configurator just ignored that there was no value. Is there a way to do this in Kinetic?
With classic I have used making a read only field required and programmatically filled it in as you have.
The Kinetic configurator still has a number of issues so don’t accept behavior that worked in classic but not in Kinetic. If something worked in Classic it should work in Kinetic.
I suggest opening a ticket.
Another approach I use instead of setting a control as required is to have a text box that I fill with messages and the like telling user what they need to correct. if they correct everything the text box will be empty. This way I can craft detailed explanations of what needs to be addressed. Such as “Control X must be greater than Control Y.” Or “An entry in Control X is required”
Then as part of the Page On Leave code I test to see if the textbox is empty. if Not i set args.Cancel = true preventing them from leaving until they resolve things.
What is interesting is that if when the page/configurator loads and the field is active it honors the required. If it subsequently is disabled by a rule then it still is a required field. If it starts disabled and gets enabled it is not required. It is pulling the state at load and then never refreshing it.
Another issue I have run into is the refreshing of dynamic lists, particularly with multiple pages, I have to put a button on the page to have it run the code to refresh the lists since even with it on the OnLoaded rule for the page it does not run.
At this point I am fairly certain that the switch to Kinetic was 1000% done solely because they knew people would just say screw it and drive revenue to Epicor Professional Services to rebuild all of the stuff that worked properly in Classic.
Best of luck with a ticket, I don’t hold out much hope for the ticket system since they can now give you a hyper-link to Ideas and close the ticket as ‘working as designed’.
It looks like most of my configurators will have to be rebuilt from scratch, a few are light and work fine but some are pretty heavy, the alternative being to do like you suggested and find a way to write custom code to do the validation that worked perfectly out of the box in classic.
Refresh doesn’t clear out invalid values
Refresh will show the value instead of the display value
Just opened one ticket where if the UD Method for dynamic list references decimal fields it just doesn’t work
My conversions from classic to Kinetic for the most part do work but look ugly as all get out. So screen cleanup is required. If you have any UD methods that return something via an “out” parameter to the client these will break. I believe in the latest release they have added some error reporting to help with this. You can use “out”: on methods on the document and MOM rule side, just not anything that talks to the client.
Kinetic appears to struggle with the concept of “pages” that we used a lot in Classic. So I have experienced issues with classic conversion to Kinetic that use pages. With panels the need for pages may go down.
There is some ability to control size of things but if you make things too small in the designer it can be really challenging to select the control to work on it.
Exporting often is really important, Kinetic will error out at times and I have lost my work. Error reporting is very minimal or non existent at times that leaves you with very little to go on figuring out what you did wrong.
I have not been able to test it but in theory you could write an ud method to check if the fields are set to read only and then set required to false for that felid and set to true in the opposite.
As @Jkinneman said dynamic lists in kinetic configurators are still hit and miss. When we tried to uplift classic configurators they all pretty much broke because of the dynamic list problems. I first tried rebuilding them one for one looking at the classic and building it in Kinetic just to find more dynamic list problems. We finally decided to just rebuild from scratch and had to come up with creative work arounds for getting our dynamic lists to output visually how we wanted.
I have also had the configurator eat the events associated with some fields. If you look in the event tree they exist but the data saved in the event linked on the field is not the same. Say On field changed execute C# for the field in the event tree showed blank. On the properties tab, actions, on field changed, execute C# we would have code. This is a big problem when it is the bind event meaning it is not actually storing the data in the field, think combo box selected value showing on you screen but the system thinking it is empty. We did find that we could make the exact same field with a different name and tell it to set the old field equal to the new field and the data would be stored, we may have had multiple things written against this value when it would magically break and didn’t want to have to find all the spots it would break.
Some of this may also be fixed in 2024.1 as we are still on 2023.2
That most configurators are made up of mostly combo boxes that they don’t work consistently is frustrating.
For some of the issues in Kinetic I think they are more situation driven than with issues in Classic. I have some issues that are very consistently going wrong in my configurator but support isn’t able to duplicate.
My theory of the challenge of bringing the configurator into Kinetic is in previous versions the configurator was its own beast. But in Kinetic they are trying to bring it into the general fold. Some of the configurator’s behavior is outside of the normal behavior expected from controls in non-configurator screens. That makes it a bit more challenging to get them to behave as we expect in the configurator.