I think what you did makes sense to me now Ernie why that worked after looking at the source code for the Ice.Lib.EpiClientLib library others have pointed us toward.
Here are the relevant functions (I think):
bool ShouldShowKineticAlert() in Ice.Lib.Framework.EpiBaseForm
So if you can read C#, you’ll see that a bunch of conditions need to be met for Epicor to show the nag, aka the Kinetic Alert, in the first function. The second function is one of those conditions, and has a few more conditions, and one of them is the “-KineticUI” argument has to be present in the menu entry for the program you’re running. Thus why your DMT would seem to fix the nag. I am a little nervous to remove all those -KineticUI from the Menu table records without knowing there is a way to add them back if needed - have you observed something adding those back in then @Ernie or think you’ll have to DMT that back in if you ever start using some Kinetic UI screens?
Anything you can remove with a DMT, you can put back with a DMT… so if removing the “-KineticUI” flag undoes something you find repulsive you can always just add it back. I haven’t found any issues with having done so.
Additional warning though… most likely you’ll have to re-perform this DMT with each Service Pack level release. So far we haven’t had to on any bug-fix release, but you never know what Epicor might do.
Good point about putting things back… I guess I better just keep careful records somewhere of where it gets removed if I got that route. And it might make turning it back on “by department” tricky – recursive SQL might be required.
Lot of comments in here, but you are doing it correctly the first time. However, it is confusing because of a bug in menu maintenance.
In menu maintenance you set it on the top level node and it cascades down to child records that’s the intended replacement for the prior kinetic application maintenance cascading feature. There is a known bug where it may not show you the correct value for those two checkboxes after you do so thus the confusion. It should actually be cascading down though and saving correcly - if it’s not or you see inconsistency I’d recommend you contact support in case we’ve some other unknown issue (or they can help explain why it’s doing something that seems inconsistent)
This will disable KineticUI Globally. (As far as I can tell)
̶(̶D̶o̶e̶s̶n̶’̶t̶ ̶a̶f̶f̶e̶c̶t̶ ̶s̶n̶o̶o̶z̶e̶ ̶b̶a̶n̶n̶e̶r̶,̶ ̶i̶t̶’̶s̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶.̶)̶ This one will disable the snooze banner!
//Method Directive - Post Processing
//Ice.BO.Menu.GetRowsTranslated
/̶/̶D̶i̶r̶e̶c̶t̶i̶v̶e̶ ̶N̶a̶m̶e̶:̶ ̶S̶h̶o̶o̶_̶K̶i̶n̶e̶t̶i̶c̶_̶S̶h̶o̶o̶
//Directive Name: Shoo_Kinetic_Shoo_NoNag
//Description: Do not launch Kinetic Forms
//Requires Client Restart
//Method Directive Code
foreach(var row in result.Menu)
{
//row.DefaultFormType = "URL";
//row.DefaultFormType = "DEFAULT";
row.DefaultFormType = "BASE";
//No Nag (Might need testing further.)
row.Arguments = row.Arguments.Replace("-KineticUI", String.Empty);
}
So I believe I have a good working solution now, and it’s a combination of knowledge gleaned from this thread - our solution provides a No-Kinetic-UI experience to users now, but allows us to start switching screens to Kinetic for our users on a screen-by-screen basis without undoing everything.
First, we use the Menu Maintenance (Kinetic version!) to switch Menu.DefaultFormStyle to “BASE” on most all of the menu entries recursively under MAINMENU in Menu table, using that Kinetic Options 3-dot menu entry shown in screenshot in original post. It does work, even though bug prevents you from thinking it does, as @bconner confirmed for us. Thanks @hmwillett and @Ernie for also pointing toward this and providing other methods some may want to use.
Second, used a modified version of the BPM directive @klincecum created in order to hide the nag to “Try Kinetic UI” from our users. This modified version only removes the Menu argument if we have the Menu record set to Classic.
//Method Directive - Post Processing
//Ice.BO.Menu.GetRowsTranslated
//Directive Name: DisableKineticNag
//Description: If we have set Form to Show to Classic, disable the Kinetic nag
//Requires Client Restart
// modify the results of the returned menus
foreach(var row in result.Menu)
{
//row.DefaultFormType = "URL"; // kinetic
//row.DefaultFormType = "DEFAULT"; // user choice
//row.DefaultFormType = "BASE"; // classic
// If we're defaulting to classic form...
if (row.DefaultFormType.ToUpper() == "BASE")
{
// removing this argument makes the ShouldShowKineticAlert() method
// in Ice.Lib.Framework.EpiBaseForm not show the nag to try Kinetic version
row.Arguments = row.Arguments.Replace("-KineticUI", String.Empty);
}
}
I didn’t confirm 100%, but I’m thinking the “-KineticUI” argument may need to be left alone if in the future we want to switch a Menu entry to show the Kinetic form (i.e. DefaultFormType = “URL”).
Thanks to @hmwillett, @Ernie, @bconner, @klincecum for all contributing ideas and knowledge that ended up in our final solution. Wish I could mark multiple posts as the Solution.
I’ve observed the same thing Doug… it’s like 1-5% of the time I still get it with some random little form I launch - I thought maybe it was a process called by a process (e.g. launching Convert Quote to Order from Quote Entry) but I could be wrong about that.
Solution.