About Effective Access Permissions to Shared Members

You cannot assign access directly to a shared member. A shared member inherits access permissions from its base member, parent, or ancestor.

Oracle Hyperion Planning checks access permissions at each level, first by user, then by group, based on the member’s access permissions inheritance relationship. If multiple access permissions exist, the least restrictive access permission is applied (for example, Write access takes precedence over Read access).

This example shows how effective access to base members and their shared members are determined if the database is refreshed or created with the Security Filters and Shared Members options selected in the Refresh Database or Create Database page (see Creating and Refreshing Application Databases).

Sample Entity Members

Parent Entity	Child Entities
United States
	CA (base)
	NY
West
	CA (shared)
	NV
Sales Region 1
	CA (shared)

Table 3-2 Example of Inherited Access to Shared Members

Case	Access Permission	Effective Access for Base and Shared Member CA	Explanation
Case 1	CA (base) = None iDescendants (West) = Read	Read	CA inherits Read access from its West parent because Read is less restrictive than None.
Case 2	iDescendants (United States) = None iDescendants (West) = Read iDescendants (Sales Region 1) = Write	Write	CA inherits Write access from its Sales Region 1 parent because Write is less restrictive than Read or None.
Case 3	iDescendants (United States) = Write iDescendants (West) = None iDescendants (Sales Region 1) = Read	Write	CA inherits Write access from its United States parent because Write is less restrictive than Read or None.