Right Click access denied

[faepigrl (Kimberley)]

I have many users that get access denied on many menu items. Even thought they have access to one of them but not all the areas the menu item my be. Do they need to have access to all locations? I have been reading about context menu. Is the something that can be modified to add or remove where that menu item opens?

[jwphillips (Jonathan Phillips)]

@HeatherM helped me figure this out - and it seems you have to either go all Classic or all Kinetic.

Right-Click Questions

I have found this to be a bit buggy. One thing that has improved this functionality is to convert the targeted menu item to a Kinetic App (which removes the classic layer). If there is a three-way, with a classic in the middle, the right-click relationship seems to work once but won’t continue for the next record.

Right-Click Questions

I went into Context Menu Maintenance and changed the default menu item that is added to the Part Tracker entry of the Part.PartNum context menu … and that seems to have done the trick! The only thing is that this is the Part Tracker that I cloned under the Order Management menu - and I don’t know if that has implications beyond being a vanilla version of the Part Tracker [image]

Create a copy of the target menu item as a Kinetic App, then use Context Menu Maintenance to direct item to your new menu item.

[faepigrl (Kimberley)]

we are only using Kinetic (users use the web browser). I think my issue is more security related than context menu related but I could be wrong.

For example. They can right click and select Part Entry but they get access denied (guessing it is calling a menu path the use doesn’t have access too). In older versions it didn’t matter what menu you had access if you had part you had part and right click was never an issue.

[dcamlin (David Camlin)]

@faepigrl

(guessing it is calling a menu path the use doesn’t have access too)

Yes, this is the issue. The Context Menu is pointed to a specific Part Entry path. So if it is a Sales Person trying to access the Part Entry in Production Management, it will fail (if they don’t have access to that menu/folder, as an example).

I don’t believe there’s anyway to correct this. The Context Menus are 1-to-1 (unfortunately).

One solution, which I’ve done, is to create a new menu and put somewhere everyone has access to. Then you can control access strictly by menu security (allowing/disallowing specific roles and/or persons) and not based on security of parent menu folder structure.

[faepigrl (Kimberley)]

UGH !! I have heard about this. Just seems like over kill and ridiculous to have to build extra menu items to avoid some security issues.

[Randy (Randy Stulce)]

We ran into menu security issues with our Data Collection users and support turned a blind eye. I voted for an idea a long time ago about having them revamp menu securities since Kinetic is just making the situation worse. I should go see if it’s dead or still around.

[visionaire (George Hicks)]

There are many Kinetic Ideas to vote on for Menu Security, so search there and vote, but I believe this one reflects this particular request you have, and is a good one.

[kananga (John K)]

That’s not perfect but close enough to improve the security situation. I’ve actually searched for this before because the security methods make me sad but never turned this one up. I’m off to go vote and comment. Copying below…

1. Securing navigation to the processes instead of securing processes themselves misses the point of security.
2. The inconvenience of having to maintain alignment of security for a single process in many different places is a secondary issue but adds a substantial unnecessary workload.
3. That’s made unnecessarily difficult by the inconsistent naming of menus. BAQ’ing Ice.Menus can’t produce a consistent process ID to group them by, because 40% of Menu data isn’t returned by BAQ. The REST API returns the rest of that data, but querying menus is broken. GET requests to Ice.BO.MenuSvc only return a few menus, whether unfiltered, MenuID gt '', top=100, etc.
4. Managing security at navigation also causes Epicor to punch holes in client’s managed security. When updates add a new menu instance, that new instance is defaulted to ‘security manager only’ or ‘allow access to all users’, and the only way for people managing security to know about these is to audit all of their menu security before and after every software update (see item# 2).

All of these are security problems only because security is managed at navigation instead of at the securable.