Confused about the realtionship between the different item types

I thought I understood the semantics of the hierarchy but when playing around w/ the MMC Snap-in console and using the built in 'Check Access Test' the results confused me. Let me describe my hierarchy, the authorizations I assigned and highlight expected
results vs. actual results.

Application_A

<Item Definitions>

<Roke Definitions>

Role_1 (has task_1, task_3, operation 1)

Role_2 (has task_2, operation_1)

<Task Definitions>

Task_1 (has operation_2, operation_3)

Task_2 (has operation_2, operation_3)

<Operation Definitions>

Operation_1

Operation_2

Operation_3

Authorizations Check Scenario 1:

<Item Authorizations>

<Role Authorizations>

Role_1 - User_A is Allowed

Role_2 - User_A is Denied

When Running 'Check Access Test' for User_A I got the following results:

Role_1 - Allowed (expected Allowed)

Task_1 - Allowed (expected Allowed)

Operation_2 - Denied
(expected Allowed)

Operation_3 - Denied
(expected Allowed)

Task_2 - Denied (expected Denied)

Operation_2 - Denied (expected Denied)

Operation_3 - Denied (expected Denied)

Operation_1 - Denied
(expected Neutral)

Authorizations Check Scenario 2:

<Item Authorizations>

<Role Authorizations>

Role_1 - User_A is Allowed

Role_2 - User_A is Allowed

<Task Authorizations>

Task_1 - User_A is Allowed

Task_2 - User_A is Denied

When Running 'Check Access Test' for User_A I got the following results:

Role_1 - Allowed (expected Allowed)

Task_1 - Allowed (expected Allowed)

Operation_2 - Denied (expected Allowed)

Operation_3 - Denied (expected Allowed)

Task_2 - Denied (expected Denied)

Operation_2 - Denied (expected Denied)

Operation_3 - Denied (expected Denied)

Operation_1 - Allowed (expected Allowed)

It appears that permission checks perform 'bit wise' AND operations across each level in the hierarchy, applying the most restrictive authorization; not what I would have expected. Being what it is, how would you suggest I organize my permissions to
get the desired affect. Real world example:

I've got two forms (Form_1 and Form_2), both with two corresponding permissions (Modify, Read Only). I want to assign user_a with read_only rights on form_1 but have full rights on form_2. Right now it seems the only way to make this happen is
to treat the form as an application rather then a role or a task.

If
User_A has Deny on the root Folder … he never could read files inside root folder and subfolders.

If
User_A has Allow on roof Folder … permissions depends on subfolders … and so on.

When you say:

“I've got two forms (Form_1 and Form_2), both with two corresponding permissions (Modify, Read Only). I want to assign user_a with read_only rights
on form_1 but have full rights on form_2. Right now it seems the only way to make this happen is to treat the form as an application rather then a role or a task.” … you are implicitly admitting the Read_only on form1 must be a “different
operations” of Read_Only on form_2.

What I suggest is …

1)Don’t think in terms of “generic” operations … on all forms … but think in terms of “specific”
operations for each form;
i.e.: “read on form1”, “write on form1”, “read on form2”, “write on form2” (are all operations) and so on (they are really different operations that can be assigned to different Roles (Users))

2)Tasks are operation aggregators (Use a Task to group several operations, then just assign a task to a Role – this is more quickly instead
of assign several operations to a Role)

3)Users in the same Role can performs the same “operations”
i.e. “Managers” Role with all read/write operations (for each forms)

First, I REALLY appreciate the rapid feedback and the time you've put into this project. It's really appreciated.

Regarding your response....my expectations were based on the folder/sub-folder/file metaphore. However, the key difference is that file systems are trees where the models we can build using NetSQLAzMan could resemble DAGs. So what I observed
(and caused the confusion) was that if a user was associated w/ multiple roles for example but w/ different permissions, the permission of the operation (file) was set to be the most restrictive if there were multiple paths to it. This is also true of
tasks (sub-folders).

Anyway, I think I understand how it's organized and have re-worked how model of authorizations should map onto NetSQLAzMan's hierarchy.