The above test was done on a separate machine to verify that it was not a machine specific behavior.......

I updated to 3.4.5 and the problem persists. I can give access to a test site if desired....

Does this issue still exist in 3.6 Beta 2?

Don't know... I will have a look. To be honest I have not confirmed it on 3.5.x either. I will let you know.

This problem still exists in 3.6 Beta 2. Frustrating!
I followed the original steps outlined above and got the same result.

I am sorry for your troubles, but you should read Joomla docs, both issues that you mentioned are correct and expected behaviour (i mean how the system is intended and designed to work)

Case 1

For the test user I add the DemiAdmin group as well as Administrator. - Tested and had no access to admin functions. ... End up with view access to Admin (back end). Unable to make changes or view article content, user data, etc.

The above is correct behaviour

• if a user is member is member in multiple usergroups, and then a permission is explicitely denied for a usergroup, then user will not be granted the permission

Case 2

I did note that when I went to components (ie Articles component) to set different permission for DemiAdmin group, all the fields that I had set to "Not Allowed" in Global show as "Not Allowed (Locked)"

The above is correct behaviour

• after you explicitly DENY a permission then you cannot enable further down the tree e.g. in your case you denied for the usegroup DemiAdmin in Global configuration, meaning that you cannot enable at components, and categories, and records

Please read docs on how ACL heritage works in Joomla

in order to do what you want you need to use "Soft deny"
Soft deny is

• current user group is set to inherit
• all its parent groups (are set "inherit" or "Not set" (for global config))

This can be closed

Thanks for taking the time to reply...
I am happy to close this issue. Frustrating that it used to work well prior to 3.4. I re-read the ACL as suggested. The combination of what you wrote above and the documentation I was able to get to the solution.
My observations are as follows:

• I did not find any documentation that explicitly stated the A explicit "Deny" takes Precedents over an explicit "Allow." at the same level of hierarchy. I could only find.. "This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect"

• You can't have different security settings at the same hierarchy level which both have different permissions, assigned to the one individual as a Deny will deny both regardless (see previous dot point).

The solution to this current problem is to create user groups with "Inherit" and "Allow" access only, which means that you canot follow an Access Hierarchy. In the example above I am giving "DemiAdmin" access to Management functions but have to have the group as a child of the Public access (instead of Management) group to get it to work. Which is not logically correct.

Ideally if the "Allow" access had priority over the "Deny" access, the system would work as desired and the logical permission hierarchy would be maintained.

Do you have any thoughts on why an "Allow" should not have priority over a "Deny" at the same hierarchy level to maintain a logical Hierarchy?

Thanks again Georgios for your assistance. I will close this issue in a day or so to give a chance for any additional comments.

Cheers,
Alex

Folks, any further test on this should be done on staging (or RC to be released normally today) as a late ACL patch has been merged.
See #10894
and the Still known Issues.

The solution to this current problem is to create user groups with "Inherit" and "Allow" access only,

Yes, exactly what you need to do

and remember that if you ever use "(explicit) Deny", it will mean that:
1. you cannot re-allow further down the hierachy
2. any user that is member of the user-group will be denied the specific privilege, regardless of being member to other usergroups that have it

there are good reasons for the design choice, and in any case, this will not change

• without going into too many details, an important reason, for "deny" behaving like this is that it provides a guarantee, that if you set something to deny, then you do not need to search hundrends or thousands of sub-categories or even individual records, if they override the permission, which would be really problematic

anyway i don't want to discuss design choices here more, just point out that "heritage issues" that you reported, are in fact correct behaviour, and if in any Joomla version it was different, then it was bug.

J3.6 has some ACL fixes that are related to the AJAX saving of ACL that was added in J3.5.x,
but they are not directly related to this topic, still more testing is welcome ))

Thanks.... Will leave at that,,
Cheers,
Alex