When the security levels defined for applications, databases, users, and groups are not enough, Essbase security filters give 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 for Users and Applications.
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 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 for Users and Applications.
Calculation access is controlled by minimum global permissions or by permissions 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. 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.
Tip: You can view lists of filters using methods other than Application Manager:
Tool |
Instructions |
For more 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.
Note: If you use a calcluation function that returns a set of members, such as children or descendants, and it evaluates to an empty set, the security filter is not created. An error is written to the application log stating that the region definition evaluated to an empty set .
To practice creating a filter using a sample, see Mini-Tutorial.
Essbase displays the Filters dialog box.
Figure 203: Filters Dialog Box
Essbase displays this confirmation box.
Figure 204: Associate Outline Confirmation Box
Essbase displays the Define Filter dialog box.
Figure 205: Define Filter Dialog Box
Click Help for information on each option.
Note: You do not have to use the member selection tool to specify dimensions and members. If you know the names of members to filter, you can type them in. However, be sure to use quotation marks (" ") around any member names containing special characters or spaces. For more information, see Rules for Naming Dimensions and Members.
Note: For more information about functions and syntax, consult the Technical Reference in the docs directory.
Use this procedure to create a filter for Sample Basic:
Essbase displays this confirmation box.
Figure 206: Associate Outline Confirmation Box
Essbase displays the Define Filter dialog box (see Figure 205).
Figure 207: 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 examples of Figure 208 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 208: 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 this filter:
Figure 209: Filter Blocking Access to Sales or Jan
The filter blocks access to all members Sales or Jan in the Sample Basic database.
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 this view:
Figure 210: 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 this filter:
Figure 211: Filter Blocking Access to Sales for Jan
The filter blocks only the intersection of the members Sales and Jan in the Sample Basic database.
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 this view:
Figure 212: 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.
Note: @ATTRIBUTE and @WITHATTR are member set functions. Most of the member set functions can be used in filter definitions. For more information about functions, see the Technical Reference in the docs directory.
User PJones is assigned this filter:
Figure 213: Filter Blocking Access to Members with Attribute "Caffeinated_False"
The filter 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.
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 this view:
Figure 214: 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 216: Copy Filter Confirmation Box
Tip: You can create or copy filters using methods other than Application Manager.
Tool |
Instructions |
For more information |
---|---|---|
Essbase displays the Filters dialog box (see Figure 203).
Essbase displays this dialog box:
Figure 217: Rename Filter Dialog Box
Tip: You can also use the RENAMEFILTER command in ESSCMD to perform this task. See the Technical Reference in the docs directory for information.
Essbase displays the Filters dialog box (see Figure 203).
Figure 218: 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.
To assign a filter to a user or group:
The Filters dialog box appears as in Figure 203.
Figure 219: 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, this filter contains overlap conflicts:
Figure 220: 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:
FINPLAN R CAPPLAN W PRODPLAN N
He is assigned to Group Marketing which has the following database access:
FINPLAN N CAPPLAN N PRODPLAN W
FINPLAN R CAPPLAN W PRODPLAN W
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
FINPLAN W PRODPLAN N
In addition, Mary uses the filter object RED (for the database FINPLAN). The filter has two filter rows:
Figure 221: RED Filter for Database FINPLAN
The Group Marketing also uses a filter object BLUE (for the database FINPLAN). The filter has two filter rows:
Figure 222: BLUE Filter for Database FINPLAN
The effective rights from the overlapping filters are:
R | |
W | |
W |
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.
![]() © 2002 Hyperion Solutions Corporation. All rights reserved. http://www.hyperion.com |