I’m not super creative when it comes to naming things. I do still preface with UD out of habit, but then functional area and the Sequence number are my unique ID’s. Then I don’t have to worry about it being unique at least.
I certainly can confirm this issue. I was only able to workaround this kick to the “pick any painful place to get kicked” again by Epicor development, by copying an already existing UD “User Choice” menu item and just updating all the values before saving. My method allowed me to deploy a new and different Classic dashboard program. I was also able to change the Description of the source Menu Item, also a Classic Dashboard, and it saved the Description change without any problem. So, who knows.
We can change the Type on our own UDs… still a bug. @Rich do you guys have an ETA on this sir?
So this was a surprise to me. First some knowledge sharing. having a status of closed or resolved may not mean what you think. I checked with people in the know here and there is a separate value for pre defect review that says it was rejected, with PD state of closed. I do not know if you see the same fields when you look a problem but this issue was not resolved it was rejected.
Given you are all saying you still experience the issue I went and looked. The person who did the triage could not recreate it but I think that was inexperience. It is true I cannot recreate it in an ‘on prem’ installation but as you all know there are different business rules in some places in our cloud software to allow support for shared databases and this appears to be a bug in one of those areas.
Based on that I have ‘unrejected’ this issue and assigned it to the first sprint next year. that will get the primary fix into 2025.1 but since this has been around a while and the processing error was on our end I am planning to retrofit it into 2024.2 as well - it will likely be in either .9 or .10 depending on time to fix and QA’s validation schedule.
Notes for the record:
- Expand Field
- If you are supposed to put UD at the beginning of the Menu ID have the system automatically do this, or force us with an error message "Sorry your menu ID must begin with “UD” or stop telling us we should do it then allow the system to accept anything.
Great information!
Also wanted to put on the record that we’re on-prem and I was also experiencing this bug when we upgraded to 2024.1 a few months ago and I worked on converting all of our UD menus. I had to run a DMT to delete the menu, then another re-add it with the type changed to Kinetic. Wasn’t a terribly involved process, but certainly a lot more than choosing a different option in a dropdown and saving the record.
We are on-prem, for us it was us trying to change our own dashboard from Runtime to Assembly, the module was UD but it still kept throwing that error.
I’ll make sure they test both. For little or no help to your (or real value) I was unable to recreate in an on prem configuration. Not saying you are not seeing it. Just that I’m missing the ‘magic sauce’ for this one.
I’m coming into this a bit late, But is this the issue we are talking about? When I make a new menu, I can’t change the dashboard it’s using even if prefix with UD. I have to delete and re-create.
Thats the one I think, howd you replicate it?
For me, it occurs if I try to change the Dashboard to an existing menu item.
Perfect so it wasnt just me… I think @pferrington has enough data to test it, maybe the patch they are on has it fixed, nonetheless all our input’s here will help.
@jgiese.wci has also seen it in the Kinetic Menu Maintenance, because of course the blocking happens server side.
Thanks Patrick for looking into this, good luck, may the force be with you.
No, I’ve had it too.