Permission settings are conveyed across two distinct
relationship networks:
-
In
object inheritance, permissions that you set on one object can affect
many other objects. For example, a report inherits permissions from
the folder in which the report is located. This network is a simple
folder tree, with exceptions such as the following:
-
The root folder isn't the ultimate
parent. This folder inherits from the repository (through the permission
pattern of the repository ACT).
-
The root folder isn't a universal
parent. Some system resources (such as application servers, identities,
and ACTs) are not in the folder tree. For these items, the repository
ACT is the immediate and only parent.
-
Inheritance within a table or cube
follows the data structure. For example, neither table columns nor
cube dimensions have folders as immediate parents. Instead, a column
inherits from its parent table and a dimension inherits from its parent
cube.
-
Inheritance does not flow through
specialty folders such as favorites folders, virtual folders, or search
folders.
-
In
the identity relationships network, permissions that you assign to
one identity can affect many other identities. For example, if you
grant a group access to a report, that grant applies to everyone who
is a member of the group. This relationship network is governed by
a precedence order that starts with a primary (usually individual)
identity, can incorporate multiple levels of nested group memberships,
and ends with implicit memberships in SASUSERS and then PUBLIC.
The following figures
depict the relative priority and specificity of access controls within
each of these networks. From top to bottom, the elements in each figure
are ordered as follows:
-
from highest precedence (hardest
to override) to lowest precedence (easiest to override)
-
from narrowest impact (most specific)
to broadest impact (least specific)
