1. Database Administrator's Guide for Oracle Essbase
  2. Controlling Access to Database Cells Using Security Filters
  3. Assigning Filters

Assigning Filters

After you define filters, you can assign them to users or groups, which lets you manage multiple users who require the same filter settings. Modifications to the definition of a filter are automatically inherited by users of that filter.

Filters do not affect users who have the Administrator role.

You can assign filters in MaxL or in the Essbase web interface.

Note:

To assign filters, roles must be assigned at the application level. In MaxL, the application-level user and group roles are assigned implicitly, whereas in the Essbase web interface an explicit application-level role assignment is required before you can assign filters.

Assigning Filters Using MaxL

You can assign filters in MaxL using the grant MaxL statement.

Example

  1. Create a filter called filter1.
    MAXL> create filter sample.basic.filter1 read on 'Jan, sales', no_access on
        '@children(Qtr2)';
  2. Grant filter access to user1.
    MAXL> grant filter sample.basic.filter1 to user1;

Assigning Filters Using the Essbase Web Interface

To assign filters using the Essbase web interface, first make role assignments at the application level, and then assign the filters.

Example

  1. Assign roles at the application level:
    1. On the Applications page, click the Actions menu to the right of the application name.
    2. Select Inspect, and then select Permissions.
    3. Click Add Image of the Add icon. on the right hand side of the dialog box.

      A list of users and groups is displayed.

    4. Click Add Image of the Add icon. next to a user.

      In this topic, we use user1, a user with the User role, as our example.

    5. Close the right hand panel by clicking Close Image of the close (x) icon in Essbase web interface..
    6. To check your filter assignments, on the filter editor screen, click Roles.

      user1 is displayed.

  2. Create a filter called filter1 with read access on 'Jan, sales', no access on @children(Qtr2).
  3. Grant filter access to user1:
    1. On the Applications page, expand the application and click the Actions menu to the right of the cube name.
    2. Select Inspect, and then select Filters.
    3. Select filter1 and then select Roles.
    4. Click Add Image of the Add icon..

      A list of users and groups is displayed.

    5. Click the Add icon Image of the Add icon. next to user1.
    6. Click Close.

      user1 is displayed as a member of filter1.


      Image of the roles tab in the filter editor, showing user1.

Overlapping Filter Definitions

If a filter contains rows that have overlapping member specifications, the inherited access is set by the following rules, listed in order of precedence:

  1. A filter that defines a more detailed dimension combination list takes precedence over a filter with less detail.

  2. If the preceding rule does not resolve the overlap conflict, the highest access level among overlapping filter rows is applied.

For example, this filter contains overlap conflicts:

  • Access: Write. Member specification: Actual.

  • Access: None. Member specification: Actual.

  • Access: Read. Member specification: Actual, @IDESCENDANTS(“New York”).

The third specification defines security at a greater level of detail than the other two. Therefore, read access is granted to all Actual data for members in the New York branch.

Because write access is a higher access level than none, the remaining data values in Actual are granted write access.

All other cells, such as Budget, are accessible according to the minimum database permissions.

If you have write access, you also have read access.

Note:

Changes to members in the database outline are not reflected automatically in filters. You must manually update member references that change.

Overlapping Metadata Filter Definitions

You should define a MetaRead filter using multiple rows only when the affected member set in any given row (the metaread members and their ancestors) has no overlap with MetaRead members in other rows. It is recommended that you specify one dimension per row in filters that contain MetaRead on multiple rows. However, as long as there is no overlap between the ancestors and MetaRead members, it is still valid to specify different member sets of one dimension into multiple MetaRead rows.

For example, in Sample Basic, the following filter definition has overlap conflicts:

  • Access: MetaRead. Member specification: California.

  • Access: MetaRead. Member specification: West.

In the first row, applying MetaRead to California has the effect of allowing access to California but blocking access to its ancestors. Therefore, the MetaRead access to West is ignored; users who are assigned this filter will have no access to West.

If you wish to assign MetaRead access to West, as well as California, the appropriate method is to combine them into one row: Access: MetaRead. Member specification: California, West.

Overlapping Access Definitions

When the access rights of user and group definitions overlap, the following rules, listed in order of precedence, apply:

  1. An access level that defines a more detailed dimension combination list takes precedence over a level with less detail.

  2. If the preceding rule does not resolve the overlap conflict, the highest access level is applied.

Example 1:

User Fred is defined with the following database access:

FINPLAN     R
CAPPLAN     W
PRODPLAN    N

He is assigned to Group Marketing, which has the following database access:

FINPLAN     N
CAPPLAN     N
PRODPLAN    W

His effective rights are set as:

FINPLAN     R
CAPPLAN     W
PRODPLAN    W

Example 2:

User Mary is defined with the following database access:

FINPLAN     R
PRODPLAN    N

She is assigned to Group Marketing, which has the following database access:

FINPLAN     N
PRODPLAN    W

Her effective rights are set as:

FINPLAN     R
PRODPLAN    W

In addition, Mary uses the filter artifact RED (for the database FINPLAN). The filter has two filter rows:

  • Access: Read. Member specification: Actual.

  • Access: Write. Member specification: Budget, @IDESCENDANTS(“New York”).

The Group Marketing also uses a filter artifact BLUE (for the database FINPLAN). The filter has two filter rows:

  • Access: Read. Member specification: Actual, Sales.

  • Access: Write. Member specification: Budget, Sales.

Mary’s effective rights from the overlapping filters, and the permissions assigned to her and her group:

  • R: Entire FINPLAN database.

  • W: For all Budget data in the New York branch.

  • W: For data values that relate to Budget and Sales.