A user reports no longer being able to view History > List for change requests (she previously could view History > List for change requests). The user has the itil role.
I enabled Security Debugging and impersonated the user to replicate the issue. I noticed when her access is denied, the following ACL denies access:
It is strange that for this ACL the Roles evaluate true, but execution stops at Security Attribute which is not evaluated, even though there is no condition for the Security Attribute section. I would have expected it to skip the security attributes (or assume true), rather than simply stop and not evaluate.
Even stranger is that the remaining record/*/read ACLs are never evaluated. I would have expected that if the first ACL does not evaluate true, then the remaining ACLs would be evaluated until one grants access or they all deny access.
After clicking on the record/*/read hyperlink, I observe that the subject ACL is for Read on the asterisk table (*) and the column is for None (*.None).
The user has the itil role.
I tried "Insert and Stay" for this ACL, while removing the itil and admin roles and adding a superficial Security Attribute condition of "Interactive Session is true". I then re-tested and the ACL still denied access. Similarly, I replaced this Security Attribute condition with:
Impersonating is true
Has Admin Role is false (user did not have the admin role)
UserIsAuthenticated is true
Logged In is true
In all cases, I observed the below behavior where the Security Attribute condition is not evaluated. Strangely, the condition does show a checkmark icon, implying that it was evaluated and evaluated true.
Next, I tried providing the user with the "admin" role, impersonating the user, and testing this again. This time I provided a Security Attribute with "Has Admin Role is false". I noticed that the Security Attribute condition evaluates false yet the user could still view the History list yet I could not find a Read ACL which evaluated true in the security debugger.
It appears that the "Admin overrides" checkbox takes priority over any Security Attributes that might deny access otherwise, although, this is not reflected in the security debugger logs.
The user reported no longer being able to view History > List not long after the Vancouver release, which is when the Security Attribute condition was introduced.
A resolution to this issue would be greatly appreciated.
