Epicor's precedence when deciding sec code allowance per user

Kinetic ERP
1

In menu security, is there a known precedence that Epicor uses when deciding if a user has been ‘allowed’ or ‘denied’ on a particular security code?

I have been writing a function which will return if you are accepted/denied on a particular security code. However, I need to make sure that this aligns exactly with Epicor’s functionality for this.

My precedence order after looking into this (1 = high precedence, 5 = low):

  1. :white_check_mark: Security Manager → Always grants access.
  2. :x: DisallowAccess (by name) → Always denies access.
  3. :white_check_mark: AllowAccess (by name) → Always grants access.
  4. :balance_scale: AllowAll + DisallowAccess (by group) → Deny if group match, unless name is allowed.
  5. :balance_scale: DisallowAll → Deny unless name or group is explicitly allowed.
  6. :x: No matching name or group in AllowAccess → Denied.

Here is a further breakdown:

:white_check_mark: When a user is ALLOWED access

  1. Security Manager
  • If UserFile.SecurityMgr == true, access is immediately granted, no further checks.
  1. Explicit Allow by Name
  • If UserFile.Name is listed in Security.AllowAccess, access is granted, even if their group is disallowed.
  1. AllowAll is True
  • Access is granted to everyone, unless:
    • The user’s name is in DisallowAccess → denied.
    • The user’s group is in DisallowAccess → denied.
    • (But if the user’s name is in AllowAccess, that still overrides any disallow.)
  1. DisallowAll is True
  • Access is denied by default, unless:
    • The user’s name is in AllowAccess → granted.
    • The user’s group description is in AllowAccess → granted.
  1. No AllowAll or DisallowAll
  • Access is only granted if:
    • The user’s name is in AllowAccess.
    • Or their group description is in AllowAccess.

:x: When a user is DENIED access

  1. Explicit Deny by Name
  • If UserFile.Name is in DisallowAccess, access is immediately denied, even if AllowAll or AllowAccess includes them.
  1. AllowAll is True, but Group is Disallowed
  • If user’s group description is in DisallowAccess, access is denied, unless their name is explicitly allowed.
  1. DisallowAll is True, and No Match in AllowAccess
  • If user’s name or group is not in AllowAccess, access is denied.
  1. No Matching Name or Group in AllowAccess
  • If AllowAll is false, DisallowAll is false, and the user’s name and groups are not listed in AllowAccess, access is denied.

If anyone knows the inner workings of menu security maintenance, then confirmation or assistance on this would be amazing!

Thank you for the help :slight_smile:

2 Likes
2

I have never gotten that granular, but (as I’ve said before) Epicor’s Menu Security model is based on the Windows NT 3.51 model (not kidding, no typo), which essentially states that Deny takes precedence over Allow.

Your description looks accurate.

2 Likes
3

That’s not true where menus are bound to the system security groups. There are rather a lot that carve their own security path independent of standard application security. User Account Maintenance has some access checkboxes that also apply their own security method, but in parallel with security maintenance.

It’s a silly situation, given that a security manager cannot be locked out of self-granting any security. But it is what it is. Mostly an annoyance for security auditing. A less impactful annoyance when tripping over newly added security exceptions while logged in on a security manager account.

1 Like
4

@kananga is correct… and those security groups were new functionality with either E10 or E11 (probably E10). In my not-very-humble opinion, they are making a messy situation even more messy.

2 Likes