New "feature" in 2023.2

Kinetic ERP
1

Every time I think I have reached the limits of my frustration with menu maintenance and the ability to control classic vs. Kinetic UI, it gets even worse. After the upgrade to 2023.2, I am unable to even run many programs in the browser at all. Epicor helpfully tells me to “wait” while its launched in classic. Of course the menu options are disabled so I can’t change anything (without copying to current company - we have 10+ companies so that is simply not going to happen). If I am in the browser I want to run the screen IN THE BROWSER. If I WANTED classic I would be in the client.

What I would like is that:

  • I should be able to set any menu item to launch kinetic, classic, or user choice. This selection should NEVER be disabled on any menu item no matter what. No copying to current company is not a solution.
  • Epicor should ALWAYS honor my selection within the client. If I have picked kinetic, that is what should launch, period, end of story. Same if I have picked classic.
  • If I am in the browser, everything (that is available) should run in the browser. The browser should not launch my client.

On top of this frustration, epicor is now checking if the edge agent is installed when trying to just open a program in the browser. Since there is still no simple installer for the edge agent, this is a non-starter. I don’t understand why Epicor agrees it was necessary to provide a diy cloud client installer, but refuses to provide an edge installer. No my users cannot do this installation on their own, even if the urls are provided. Not going to happen.

So basically they have made the browser unusable in 2023.2 whereas before it was an avenue to start easing people to the kinetic UI. I simply do not understand, if the goal is kinetic adoption, why is every single obstacle is placed in our path to actually move users to kinetic?

7 Likes
2

Following
Pop Corn GIF by WWE

3

We brought this up in the CR and they are working on a fix.
The logic is such that if you have a customization in classic Epicor tries to launch that (it is frustrating)

You can get around this by making a new menu for just kinetic (I know not ideal)

This is something they know about and are working to fix they were trying to do something nice but the implementation didn’t account for the possibility that someone would want the browser version even if the classic is customized

5 Likes
4

I’m sorry

5

In my case there is no classic customization.

6

Me too, we don’t use classic at all and it would be wild to see a browser session launch classic when the menu says kinetic.

7

Well that’s one way to describe the experience.

8

Tagging @timshuwy, so he can see it’s more than just myself with this complaint.

im not crazy big bang GIF

7 Likes
9

Here’s the flowchart EpicCare gave me to “Explain it”:

Pasted image (1)
Pasted image (1)995×567 76.1 KB

Tim’s question to me when I said this exact same thing: “If you have a scenario where you have a custom field added in classic, but have not added it to Kinetic, wouldn’t you want the application to open the classic version in order for the user to be able to enter information into that field which would otherwise be unavailable in Kinetic?”

My answer was: It shouldn’t matter. Admins need ultimate control over what screen opens.

And here’s my suggestions for how it should work:

Q: When would I ever want to open base if I have a classic customization?

A: Maybe the only thing I did to the screen was move some fields around in classic. If that’s the case, and the upgrade to Kinetic is going to move them around anyways, it’s a pretty low priority for me to uplift that screen, but may still want the user to use it in the browser.

Q: How would you like it to behave?

A: Utilizing the ‘Form to Use’ field in the menu row to give admins complete control over what style screen opens. There will always be fringe cases where a flow chart just will not fit, and we need to retain control over those without cluttering up the menu with duplicate screens. There should be 4 options:

Auto - Use the flow you have defined as of today

Kinetic - Always open the new UX whether you’re in the browser or the smart client

Classic - Always open the classic UX whether you’re in the browser or the smart client. This can retain the “Browser First” functionality where it opens the classic screen when you’re in the browser

Environment – If you’re in the browser, open the new UX. If you’re in the smart client, open the classic UX. This would allow me to do role-based deployment of the new UX. For instance, let’s say that our Engineering Team has been voluntold to start using the new UX. Having the ‘Form to Use’ set to Environment would allow the rest of the organization to continue using the smart client and operate as usual with the classic screens while allowing the engineering team to use the browser and access the Kinetic screens whether or not there is a Kinetic layer applied to it.

Bonus: Developer Mode – Just like in classic today, there’s a developer mode toggle. I would love to see that in the new UX as well. When enabled, it would behave as follows: an admin would click on a menu item and a dialog box would pop up asking if the user would like to open Classic or Kinetic giving me the choice to be able to choose what I’m trying to alter.

11 Likes
10

You wrote out these requirements with so much more clarity and precision than my early morning ranting, its perfect. Where can I vote.

We desperately need developer mode in kinetic. The only way I can figure out to run a kinetic application is base is to literally create a new test layer to preview it from application studio. Either that or create a whole menu item JUST to be able to run a screen in base. Developer mode should let you pick classic or kinetic AND which layer to run just like in classic developer mode.

3 Likes
11

For sure on this. kills me all the time having to make a classic menu to open it in classic.

12

This BPM will fix it (for now)
FixBrowserUX_Customer Solution_4.2.400.0.cab (18.1 KB)

It just checks to see if the client is “Kinetic” and if so it clears the classic customization from the Menu Lookup and sets the Menu as Kinetic =“true” as long as it has the corresponding web resource.
If you dont trust my cab here’s the raw code (you need a condition of ContextClient.ClientType==“Kinetic”)

Post Processing BPM On: Ice.BO.Menu.GetMenuForLicenseType

foreach(var m in this.result.Menu)
{
  if(!string.IsNullOrEmpty(m.Arguments) && !string.IsNullOrEmpty(m.WebResourceURL))
  {
    m.Arguments=" -KineticUI";
    m.Kinetic=true;
  }
}

I did a couple of quick tests and seems to work fine, let me know if you run into more issues and I’ll tweak if needed.

10 Likes
13

“Hackicor” ™️

1 Like
14

Thanks Jose!

15

I feel attacked.

16

You Should Season 3 GIF by Sony Pictures Television

17

Fair enough, but at least it wasn’t me this time. :dumpster_fire:

18

“Official Response”…
Yes, we have discussed how this works, and realized during the Controlled Release that we may not have met our target for Browser first and we want to correct it.

But we also know that there are multiple passionate opinions about how this could/should be corrected. In order to properly come up with a solution that meets the needs of ALL customers, we have created a new “Epicor Idea” called Adjustment of Browser First Logic

If you care about this subject:

  1. Please go and VOTE for the Adjustment of Browser First Logic idea
  2. Once we have some votes, we will be creating an “Empathy session” (That is what Aha! calls them) where we will post some of our ideas on how to solution this. Everyone who subscribes to the idea will also be notified about the empathy session where you will be able to comment, suggest, argue, etc.

Please note that this will be one of our first “empathy sessions” so please be patient as we discover how it works (we just subscribed to this new Aha! feature).

7 Likes
19

https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-4154

Vote for this one as well

2 Likes
20

voted.