### Permission logic

The relationship between a principal (user, role or group) and the members of a group are classified into three groups:

- Allowed Set
  The members of a group visible to a principal, which are directly specified to the principal, excluding those inherited from the parent roles or groups.
- Denied Set
  The members of a group invisible to a principal, which are directly specified to the principal, excluding those inherited from the parent roles or groups.
- Unspecified members
  The members of a group that are not specified in a user's allowed/denied set or in the inherited allowed/denied set from the user's parent roles/groups. Report designer can determine whether the unspecified members are visible to a user.

A principal can have its own allowed/denied set and inherit the allowed/denied sets from its parent roles or groups. The parent allowed/denied sets will be calculated first and it is a recursive process.

The following are the detailed working logic:

- The directly defined permission on a principal always overwrites the permission inherited from its parents. That is, for a member of a group, if its permission has not been defined on a given user/role/group, the permission will inherit from the parents of the user/role/group; if it is defined, the permission will be used directly.
- If for a user/role/group a member exists in both the allowed set and denied set, the denied set has higher priority than the allowed set. In this case the member is not available to the user/role/group.
- Inheritance rule:
  - If a member is denied by any of a principal's parents, it will be denied, or else if a member is allowed by any of a principal's parents, it will be allowed.
  - If a member is neither denied nor allowed by any parent, the permission is regarded as unspecified.
- After inheritance rule is applied to a specific user, if some members are still unspecified, the status of the members will depend on the option setting whether to make them allowed or denied.

Here is the priority order:

Denied Set > Allowed Set > Inherited Denied Set > Inherited Allowed Set > Unspecified (no matter whether it is allowed or denied).

See the diagram below:

The final result of the members of a group that a principal is allowed to access will be:

({Allowed Set} - {Denied Set}) U
(({Inherited Allowed Set from parent 1} U {Inherited Allowed Set from parent 2} U ...) - ({Inherited Denied Set from parent 1} U {Inherited Denied Set from parent 2} U ...)) U
{Unspecified if allowed}

The final set of the unspecified will be:

{All} - ({Allowed Set} U {Denied Set} U {Inherited Allowed Set from parent 1} U {Inherited Denied Set from parent 1} U {Inherited Allowed Set from parent 2} U ...)

For a user, the member-level security in a business view would be like this:

{Accessible members of group1} And {Accessible members of group1} And...

Note: If all members are denied in one group regardless of whether it is set to a principal directly or to the parents indirectly, no data will be retrieved from this business view to the principal.

We will take some examples to further demontrate the relationship between a principal and the group members.

Example 1

Here we use a simple sample to describe a case when a user belongs to multiple roles.

Assume there is a group Order ID={1,2,3,4,5,6,7,8,9}, and we set member-level security on this group for a user (user1) and two roles (role1, role2) separately.

| Belong to | Allowed Set | Denied Set
--- | --- | --- | ---
user1 | role1, role2 | 1 |
role1 |  | 2,3 | 4,5
role2 |  | 3,4,5 | 1,2

The unspecified members will be {1,2,3,4,5,6,7,8,9} - ({1}U{2,3}U{4,5}U{3,4,5}U{1,2}) = {6,7,8,9}.

Assume we set the property "Allow Unspecified Members" to true, which means the unspecified members {6,7,8,9} are allowed to the user.

The final result that user1 can see when only this member-level security is taking effect will be:

{1} U ( ({2,3}U{3,4,5}) - ({4,5}U{1,2}) ) U {6,7,8,9}={1,3,6,7,8,9}

Example 2

This example is more complex. It contains four properties of the member-level security setting.

Assume there is a summary table with three groups and summary.

Region | Country | City | Summary (the count of Order_ID)
--- | --- | --- | ---
APAC |  |  | 41
| Australia |  | 20
|  | Sydney | 20
| China |  | 21
|  | Beijing | 9
|  | Hongkong | 4
|  | Shanghai | 8

And in below table, we list the member-level security setting in the left cells, and the final result a user will get are listed in the right cells.

Member-level security specified as below | User will get such result
--- | ---
Group | Allowed Set | Denied Set | Allow Unspecified Members
--- | --- | --- | ---
Region | <empty> | <empty> | True
Country | <empty> | {China} | True
City | <empty> | <empty> | True
Region | Country | City | Summary (count Order_ID)
--- | --- | --- | ---
APAC |  |  | 20
| Australia |  | 20
|  | Sydney | 20
Group | Allowed Set | Denied Set | Allow Unspecified Members
--- | --- | --- | ---
Region | <empty> | <empty> | True
Country | {China} | <empty> | False
City | <empty> | {Beijing,Shanghai} | True
Region | Country | City | Summary (count Order_ID)
--- | --- | --- | ---
APAC |  |  | 4
| China |  | 4
|  | Hongkong | 4
Group | Allowed Set | Denied Set | Allow Unspecified Members
--- | --- | --- | ---
Region | <empty> | <empty> | True
Country | {China} | <empty> | False
City | <empty> | {Beijing,Shanghai} | False
Region | Country | City | Summary (count Order_ID)
--- | --- | --- | ---
|  |  | 0