By using this website, you agree to our Terms of Use (click here)
I seem to be having issues with users not seeing the reports button on my Shipments screen. The thing that is throwing me off, is that they can get to all the reports under that button by searching them out. I assume there's more than just what's shown under access rights by screen for this (they have full access to Distribution, where Shipments and the related reports live), but I can't seem to find where I've managed to block them from using the "reports" button on the shipment screen itself.
Anyone play a lot with security who knows what I've broken?
Well, according to my VARs, inheritance get's overridden by explicit denials, which caused our issue.
The users had two roles, the first granted permission to the entire "Distribution" module. The 2nd had fragmented permissions and explicitly denied the "reports" button.
If both are defined, you get the higher access, but if one is "inherited" you get denied access due to the explicit call for denial on the other role that has been set. It's not very intuitive, but it is something that is easily fixed. Next time, I think I'll just make unique roles for my users instead of combining multiple roles to avoid this scenario.
I have this issue too and i am sure that its only a recent change that caused it. I have far too many roles and special cases for users to contemplate per user roles. I just have to be careful not to assign the same user 2 roles with overlapping access to the same object (where one role is restricted and the other unrestricted). It seems the restricted access role appears to have priority over the unrestricted one. So Acumatica is applying a "most restrictive" access rule when it comes to combining roles. This should be something configurable system wide if you ask me. I want to use a "least restrictive" rule for combining roles.
I 100% agree and it appears the "most restrictive vs least" isn't applied consistently. For example, my account has almost every single role on it and the admin role overrides most of them, unless the admin role is set via inheritance and another role isn't and explicitly says "no", then the "no" overrides my admin role.
It appears to me that:
If both roles are defined EXPLICITLY at the same level:
Higher Access Wins
(in my system, my Admin role has GRANTED for the finance module, Warehouse has REVOKED, I have both roles on and I get access)
If one role is INHERITED and one is EXPLICITLY defined at a specific level:
The EXPLICITLY defined role Wins
(This was my issue before: Warehouse was inheriting permissions that granted access to the whole module, but Data Entry was explicitly set to REVOKED, and the button was revoked for the user who had both assigned)
I don't like it and I'm not 100% sure I'm correct on all the settings, but at least I know not to expect "highest always wins" like in other platforms.
I have noticed the same thing as you pointed out. "Explicit" access trumps "Inherited" access. Otherwise, higher level access wins.
It's especially annoying when you get into field level security.
So lets say on a page field I explicitly made it view only in 1 role and in another role the page inherited Delete access, then the view only access wins. This explains my issue.
What if there were 2 roles with differing explicit access on the same field, which one wins then? If the higher level of access wins then it means in my inherited role i need to make explicit all properties that were restricted in my restricted role. Then when the 2 roles are combined, the inherited role should win over the restricted role (assuming the higher level of access wins when multiple explicit roles are combined on the same field).
@royce-lithgo That is the behavior I am seeing as I have that example running in my system. If two roles are EXPLICITLY defined, the highest appears to win. (Revoked vs Delete in my case, with delete taking precedence).