This is my first post on Epi-users! For reference, this is also my first postgrad job. I have only been working with Epicor/Kinetic for 6 months now and so far, so good. I know I met a few of you this year at Insights. It was a warm welcome and a great introduction to the community, I’m looking forward to Vegas next year!
The reason for this long post is to get some feedback from those who completed the same project for their company and hopefully provide a resource for the next person tasked with revamping their Kinetic security system. While there are dozens of posts discussing best practices, common roadblocks, and the challenge of locking down the “Right Click” context menu issue, I have not found a concise overview outlining the whole process. Many people have dropped pearls of wisdom regarding the minutiae of Kinetic security, but as someone who just started working with the system, I craved something from a bird’s eye view. It was hard to appreciate Y X Z when I was stuck on A B and C.
That’s why I would like to detail my experience dealing with this Right Click loophole and link some helpful threads I have gathered from the forum. I am more than happy to accept any criticism about my approach. This was my first major project, and I just tried to put my best foot forward.
This security project is on 2024.2.11. I do know that the nature of the Default Access field has changed when compared to the latest version. Nevertheless, I think it’s important to show my work even if it’s out of date.
-----------------------------------------------------------------------------------------------------------------------------
The whole project began when a security manager received a request from a shop employee. The employee stated that their role has recently expanded, and they now need access to a previously locked screen. After vetting the request, the security manager went to the associated security code in Menu Security Maintenance and saw this (just an example):
(For reference, we only use nonsystem groups. System groups are empty)
The menu item was attached to a SEC code with the Default Access “Allow” with all, but 4 user groups set to Default. The user belonged in one of the “Disallow” user groups, so the security manager changed the field value from Disallow → Allow. Thus, sparking a huge issue, a bug that I have coined the “Double Positive Error”.
Because the security manager explicitly changed the user group from Disallow to Allow, and NOT Disallow to Default, every group labeled “Default” lost their permission to this menu item. Dozens of users were stripped of their authorization because one user group was granted permission with the wrong method. The complaints rolled in, the change was reversed, and I was tasked with looking into the Why.
Maybe this is a known practice, that the issue is simply the Default Access field was not taken into consideration and the admin should have known better. I would argue that this Kinetic logic is not user friendly for those new to security. It’s counterintuitive to understand that there is a huge difference between Allow+Default and Allow+Allow. Setting one group to Allow shouldn’t push every Default group into the Disallow bucket - in my opinion. This doesn’t make sense to me in practice or when analyzing the data itself. Special thanks to @tsmith for posting this SEC Audit BAQ that laid out the data plainly, it was a life saver.
Let’s say I wanted only 3 groups to have permission to these SEC codes. Technically, if the Default Access is set to “Allow”, and all 3 groups were set to “Allow” again at the user group level, my want is fulfilled. All the Default groups can’t access the menu items because at least one user group was explicitly set to Allow+Allow. Yet when looking at the data through this BAQ, this is the result:
I think most people would read this as the menu item is wide open, rather than these 3 groups only having access. The wildcard in the Allow List doesn’t mean anything. I think this is an issue, and my solution to make this process simpler is to establish consistency amongst all SEC Codes. In our system, most codes’ Default Access fields are set to Allow, some Disallow, few set to None. I have read that many consultants prefer keeping things positive. Against conventional wisdom, I decided the best approach is to set every code to “None” and set every permission at the user group level. Nothing needs to be inferred. No wildcards are used. If a group has access, it will be explicitly listed in the data.
So, the mission has been defined. The goal is clarity in the data, establish consistency in Default Access, and lock down every menu item to eliminate the right click loophole WHILE keeping every user permission the same. We don’t want anyone to lose access to a screen they need.
I decided to start tackling the share codes first. Multiple screens can share an SEC code, and the same screen can be stored in any amount of folders. Why doesn’t every unique screen have its own SEC code? Who knows. Regardless - Every path needs to remain open, but all parent folder authorizations need to be carried down to the menu item level. A tricky thing to document. I thought this was the best way to get my bearings.
The SEC Code stated up top, and then each menu item’s individual path below. Having every single Allow list and Disallow list accounted for makes it easier to calculate the final result. I think when the goal is to keep permissions the same, creating the Allow list first is the priority. Reflecting the Allow list result to the Disallow list was a key sanity check while working through these.
In this example “Part Allocation Template” is a menu item that is wide open to any Right Click context menus. Should everyone be allowed in this screen? If not, the parents’ permissions need to be brought down to avoid an unauthorized user from getting in. Currently this screen is vulnerable to a context menu click through.
“Part Allocation Template” is in three different folders. Between the three parent Setup folders, groups ADMN, PURC-Setup, and CSRVSetup need to have access. Resulting in:
- Allow List = ADMN~CSRVSetup~PURC – Setup
- Disallow List = The rest
Done. That is the result and should be put in the DMT. This menu item/SEC code is now locked down. (Menu items that only exist in one folder should simply just adopt the parent’s authorizations to be “locked down”)
After going through the tedious process of documenting 250+ shared codes, I moved onto creating the DMTs for each system folder. Using the Menu Maintenance structure for organizing the folders made the DMTs a manageable size.
“Personally I like to keep the same menu structure, as this aids the users in navigating when they are using and documentation, like online help or the ELC. The whole, “Setup, General Operations, Reports” after a while you just eat sleep and breath the menu structure.” - @Hally
I ended up with 40 DMTs total when it was all said and done.
I found it helpful to have two documents for each folder. A “worksheet” that followed the same structure as the DMT, but with Menu IDs listed, and the parent folders/shared codes color coded. Having a worksheet for reference helped me to audit my work and was much easier to read than the plain .CSV DMT file. Storing the completion logs also makes things neat.
(Going to Menu Maintenance → selecting the folder → filtering the menu items in ascending order → exporting to excel) gave me the skeleton of the DMT. There will be repeats as multiple menu items have the same SEC code. I preferred to keep the duplicates in the worksheet and remove them from the DMT. Identifying the shared codes and copying and pasting from the master sheet made the process a lot quicker too.
The DMT itself has just four columns:
Results!
Going through the gauntlet of end users testing has not yet started. From first glance, it appears the system is locked down, and the right-click loophole is now closed. All SEC codes have the default access of “None” as well. We will see what issues testing reveals, and then the process of refining each role can begin.
I think my main concern is how long the security structure lasts. It was confirmed that the so called “Double Positive Error” was an intended feature in 2024.211. But in 2026.100.9, the Allow+Allow permission no longer kicks out the Allow+Default user groups. If there are new menus added: will they come in with Allow, None, or Disallow for their Default Access? It’s hard to plan your security around objective truths and have them change down the line. For example, I have read multiple posts discussing how a user in two conflicting security groups will not have access to said menu. If they are in a group that’s Allowed, and one group that is Disallowed, the menu should be inaccessible. To my surprise when testing, this wasn’t the case. Users in conflicting groups did have access. Which was good news for me, I was worried I would have to reassign and redefine every user/group because of all the changes I made along the way. If this truth ever reverses, then I am in deep trouble.
I understand rolling with the punches and that updates are well intentioned. I think my approach protects itself from most objective truth changes. Whether user groups conflict again, whether double positives or negatives affect Default Access, whether None is removed entirely, I think explicitly assigning every group for every menu is the way to go. The wildcard * feature has sadly lost my trust. While it might be more work updating additional menus, I think it is a long-standing method. And if it does explode, I will at least have a clear picture of the problem with this explicit data.
To be fair, I am not in a place to make any grand statements. If anyone has a better understanding of the history of security maintenance and any criticism, I am all ears.
To end I would like to share the posts that helped me throughout the project. I think there are a lot of gems in these threads, I appreciate the help!
BAQ: Menu Security Report
User Security
Setting up Menu Security via groups
Menu Security - None vs Disallow?
Security, Groups, Users & Menu Access
Best Practices: Menu Maintenance?
And the Holy Grail - the first thread I read
Security Groups/Users limited menu item access
Thanks everyone 
