![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
When the security levels defined for applications, databases, users, and groups are not enough, the Hyperion Essbase Database Filter layer gives you control over security at the most detailed level. Filters let you control access to individual data within a database, by defining what kind of access is allowed to which parts of the database, and to whom these settings apply.
If you have the role of Supervisor, you can define and assign any filters to any users or groups. Filters do not affect you.
If you are a user with Create/Delete Applications privilege, you can assign and define filters for applications you created.
If you have the role of Application Designer or Database Designer, you can define and assign filters within your applications or databases. For more information about privilege levels, see Managing Security at Global and User Levels.
This chapter contains the following sections:
Filters control security access to data values, or cells. You create filters to accommodate security needs for specific parts of a database. When you define a filter, you are designating a set of restrictions upon particular database cells. When you save the filter, you give it a unique name to distinguish it from other filters, and the server stores it in ESSBASE.SEC
, the Hyperion Essbase security file. You can then assign the filters to any users or groups on the server.
For example, a manager designs a filter named RED, and associates it with a particular database to limit access to cells containing profit information. The filter is assigned to a visiting group called REVIEWERS, so that they can read, but cannot alter, most of the database, while they have no access at all to Profit data values.
Filters are composed of one or more access settings for database members. You can specify the following access levels and apply them to data ranging from a list of members to an individual cell.
Any cells that are not specified in the filter definition inherit the database access level. Filters can, however, add or remove access assigned at the database level. This is because the filter definition, being more data-specific, indicates a greater level of detail than the more general database access level.
Note: | Data values not covered by filter definitions default to the access levels defined for users, and secondly to the global database access levels. For more about global and user security, see Managing Security at Global and User Levels. |
Calculation access is controlled by minimum global permissions or by privilege levels granted to users and groups. Users who have calculate access to the database are not blocked by filters: they can affect all data elements that the execution of their calculations would update.
To define a filter means to do any of the following things:
Before defining a filter, you must connect to the server and select the database associated with the filter.
To define a filter for the selected database, choose Security > Filters. Hyperion Essbase displays the Filters dialog box. Begin with this dialog box for all filter definitions, whether you are creating, deleting, editing, copying, or renaming a filter.
If you want only to view a list of filters for the selected database, this dialog box shows a list of filters.
![]() |
You can also use display filter in MaxL or the LISTFILTERS command in ESSCMD to perform this task. See the online Technical Reference in the DOCS directory for information.
|
You can create a new filter for each set of access restrictions you need to place on database values. There is no need to create separate filters for users with the same access needs--once you have created a filter, you can assign it to multiple users or groups of users. However, only one filter per database can be assigned to a user or group.
To practice creating a filter using a sample, see Mini-Tutorial.
Hyperion Essbase displays the Filters dialog box.
Figure 18-1: Filters Dialog Box
Hyperion Essbase displays the following confirmation box.
Figure 18-2: Associate Outline Confirmation Box
Hyperion Essbase displays the Define Filter dialog box.
Figure 18-3: Define Filter Dialog Box
Click Help for information on each option.
Note: |
For more information about functions and syntax, consult the online Technical Reference in the DOCS directory.
|
Hyperion Essbase displays the following confirmation box.
Figure 18-4: Associate Outline Confirmation Box
Hyperion Essbase displays the Define Filter dialog box (see Figure 18-3).
Finances
in the Filter Name text box.
Finances
, to match the following example:
Figure 18-5: Sample Member Specifications in the Define Filter Dialog Box
See the instructions for creating a filter (see Creating a New Filter).
This filter defines the following access plan:
The following examples illustrate different ways to control access to database cells. Data can be protected by filtering entire members, or by filtering member combinations.
Filtering members separately, by defining access for each member in a separate row of the Define Filter dialog box, affects whole regions of data for those members. Filtering member combinations, using one row in the Define Filter dialog box, affects data at the member intersections.
Figure 18-6: How Filters Affect Data: AND/OR Relationships
Figure 18-7: How Filters Affect Data: AND/OR Relationships
To filter all the data for one or more members, define access for each member on its own row in the Define Filter dialog box. Filter definitions on separate rows of a filter are treated with an OR relationship.
User KSmith is assigned the following filter preventing any access to the members Sales or Jan in the Sample Basic database:
Figure 18-8: Filter Blocking Access to Sales or Jan
The next time user KSmith connects to Sample Basic, she has no access to data values for the member Sales or for the member Jan. Her spreadsheet view of the profit margin for Qtr1 looks like the following:
Figure 18-9: Results of Filter Blocking Access to Sales or Jan
All data for Sales is blocked from view, as well as all data for January, inside and outside of the Sales member. Data for COGS (Cost of Goods Sold), a sibling of Sales and a child of Margin, is available, with the exception of COGS for January.
To filter data for member combinations, define the access for each member combination using a single row in the Define Filter dialog box. A filter definition using one row and a comma is treated as an AND relationship.
User RChinn is assigned the following filter which blocks only the intersection of the members Sales and Jan in the Sample Basic database:
Figure 18-10: Filter Blocking Access to Sales for Jan
The next time user RChinn connects to Sample Basic, she has no access to the data value at the intersection of members Sales and Jan. Her spreadsheet view of the profit margin for Qtr1 looks like the following:
Figure 18-11: Results of Filter Blocking Access to Sales, Jan
Sales data for January is blocked from view. However, Sales data for other months is available, and non-Sales data for January is available.
You can use filters to restrict access to data for base members sharing a particular attribute. To filter data for members with particular attributes defined in an attribute dimension, use the attribute member in combination with the @ATTRIBUTE function or the @WITHATTR function.
User PJones is assigned the following filter, which blocks access to data for caffeine-free products. "Caffeinated_False" is a Boolean-type attribute member in Sample Basic, in the Pkg Type attribute dimension. This attribute is associated with members in the base dimension Product.
Figure 18-12: Filter Blocking Access to Members with Attribute "Caffeinated_False"
The next time user PJones connects to Sample Basic, he has no access to the data values for any base dimension members associated with Caffeinated_False. His spreadsheet view of first-quarter cola sales in California looks like the following:
Figure 18-13: Results of Filter Blocking Access to
Caffeine-free Products
Sales data for Caffeine Free Cola is blocked from view. Note that Caffeine Free Cola is a base member, and Caffeinated_False is an associated member of the attribute dimension Caffeinated (not shown in the above spreadsheet view).
Figure 18-15: Copy Filter Confirmation Box
![]() |
You can also use create filter as in MaxL or the COPYFILTER command in ESSCMD to perform this task. See the online Technical Reference in the DOCS directory for information.
|
Hyperion Essbase displays the Filters dialog box (see Figure 18-1).
Hyperion Essbase displays the Rename Filter dialog box.
Figure 18-16: Rename Filter Dialog Box
![]() |
You can also use the RENAMEFILTER command in ESSCMD to perform this task. See the online Technical Reference in the DOCS directory for information.
|
Hyperion Essbase displays the Filters dialog box (see Figure 18-1).
Figure 18-17: Delete Filter Confirmation Box
Once you have defined filters, you can assign them to users or groups. This lets you manage multiple users who require the same filter settings. Modifications to a filter's definition are automatically inherited by users of that filter.
Filters do not affect users who have the role of Supervisor. Only one filter per database can be assigned to a user or group.
The Filters dialog box appears as in Figure 18-1.
Hyperion Essbase displays the Assign Filters dialog box:
Figure 18-18: Assign Filters Dialog Box
If a filter contains rows that have overlapping member specifications, the inherited access is set by the following rules, which are listed in order of precedence:
For example, the following filter contains overlap conflicts:
Figure 18-19: Filter with Overlap Conflicts
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 data points, such as Budget, are accessible according to the minimum database permissions.
Note: | If you have Write access, you also have Read access. |
Changes to members in the database outline are not reflected automatically in filters. You must manually update member references that change.
When the access rights of user and group definitions overlap, the following rules, listed in order of precedence, apply:
User Fred is defined with the following database access:
He is assigned to Group Marketing which has the following database access:
User Mary is defined with the following database access:
She is assigned to Group Marketing which has the following database access:
In addition, Mary uses the filter object RED (for the database FINPLAN), which has the following filter rows:
Figure 18-20: RED Filter for Database FINPLAN
The Group Marketing also uses a filter object BLUE (for the database FINPLAN) which has the following filter rows:
Figure 18-21: BLUE Filter for Database FINPLAN
The effective rights from the overlapping filters are:
R | Actual |
W | For all Budget data in the New York branch |
W | For data values that relate to Budget and Sales |
The access level for unspecified members is the inherited access level of the database (in this case, Read).
For more sample scenarios, see Security Examples.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Copyright © 1991-2000 Hyperion Solutions Corporation. All rights reserved.