I Still Don't Understand Security Groups and Menu Security

Kinetic ERP
1

I am having trouble tracking down a security issue. It really comes down to the fact that I don’t get how Epicor does user security and menu items.

For example, the Job Tracker Form. In Menu Maintenance, I can see it is not restricted, and it is set to allow for everyone. No one has been granted selected access or anything. My data collection users (that don’t have individual accounts, and just login with a generic data collection account) can open job tracker without issue. But another user that also has the same data collection access group cannot access job tracker. With the error that the user is not allowed or module restrictions or something.

Pointed questions:
When I create a security group, and then assign the group to a user, how do I assign what can and can’t be access from that group?

If a particular user can’t get into Job Tracker (for example), how do I locate the correct security group to add to the user to authorize that user to user the job tracker?

Thanks!!

2

Nate,

I’ll start with the questions - and then explain our approach if you want to read that much :slight_smile:

Once you add a user to a User Group, they get access to any menu levels controlled by a Security ID that has that User Group listed on it - and to all Security ID’s set to “Allow All”. You also need to watch any “Disallow Access” entries - lots of people overlook that, and I try not to use it.

I open both User Maintenance (to the user Groups page) and Menu Maintenance. Then I travers the Menu in Menu Maintenance as though I’m the user and starting from the top. At each branch, check the Security ID for Allow/Disallow User Groups and make sure the User Maintenance form show that group. This always works for me and doesn’t take but a few minutes.

There is also a Menu Security Audit Report - but it can be super huge. It’s pretty good if you don’t want to use my method above.

The longer bits & what we try to do…
This can get real complicated because menu items like Job Tracker appear in like 10 different places in the overall menu structure. The best I can all figure is that certain accounting folks need the Job Tracker but not the rest of production sub-menus, so there’s a copy of it the Accounting sub menu. So Epicor’s base menu structure is based on that kind of theory, in general.

Personally, I don’t use UserID’s inside Menu Maint. - unless it’s a very, very specific reason. Plus, I’ve convinced my folks of a few things:

  • IT/Engineers and Accounting Mgmt are the only folks who can get into ANY of the Setup menu branches.
  • Everyone can get into the Reports branches
  • And that accounting folks get everything in accounting under their job-related menu (AP or AR, etc.) and the same goes with other functional groups. I’m not giving or taking away things under General Operations (or Setup, or Reports) between people who work in the same department.

***These rules are OK for us because we’re not goverened by any sort of rules, compliance, or national security stuff. Thank God.

Lastly - I’ve create a top level menu item for our Custom stuff. Dashbaords, BAQ reports, specail UI stuff, etc. Everyone has access, but in that folder, I have a few IT-ONLY items and security has been modified as such.

In all of this, I’ve only needed to create like 5 new Security ID’s inside Menu Maintenance.

So if you have all kinds of complicated rules and stuff, this will be difficult. I’ve talked to folks who basically have built each User Group/Department their own Top level menu item, and just put their stuff in there. Then things are real easy - but to get there takes a LOT of work.

Generally I took the approach that in each department there are managers, processors/power users, and data entry folks. I end up having those three user groups in some form for each department. In Menu Maintenance, the groups are just assigned to the menu branches that match. If the Accounting guys need Production reports, then I add that user group to the menu security IDs for Production Mgmt/JobMgmt/Reports. We don’t have too much crossover except for the managers. Almost all the top/1st/2nd level menus have all the manager groups, and almost 100% of the 2nd level menus are set to 'Allow Access to all".

5 Likes
3

This is a great idea! I skimmed through the folder structure for the menu, and realized he is probably not using the right ‘door’ to get to job tracker. At some point someone came over to help him and pulled up Job Tracker using the executive analysis menu. That is probably how they access job tracker, but this user didn’t have permissions to use that menu. I just asked him to try getting to Job Tracker from Production Management instead and it worked like a charm!

Thank you so much for this overview. I have a much better idea of how the permissions are setup now, and I can confidently find and fix permissions issues other have asked me about in the past.

Have a great day!

4

Most welcome Sir - glad I could help.

5

I’ve tripped over your same issue several ways, often due to context menu paths (right click / open with) or some other shortcut path. It’s not great that app security is set at the app’s menu instance instead of at the app itself but that’s the way it is. I’ve just taken to querying the zmenu baq when updating security to find all the instances of an app in the menu structure and making sure their security map matches regardless of parent menu security.

…Which is why relying on the menu structure rather than the app level for access security isn’t great. That does prevent someone from using the app by navigating to it in the menu, but not from other angles. Context menus, home page shortcuts, or sufficient cleverness will still launch an app that a user can’t manually navigate to via the menu hierarchy.

Someday I’ll take a minute to build up a couple of nice pretty BAQ’s to watch for security footguns like these and will try to remember to share them.

2 Likes
6

You may also want to listen to /watch Jose and Bryan talk about security with some jerk on the EpiUser Podcast.

1 Like