标签:设计
简单的分为两步:
1、Pentaho中配置角色
2、Cube中增加Role
配置角色:
Cube中增加Role
附上官方文档配置中的Cube设计
Roles are defined by <Role>
elements, which occur as direct
children of the <Schema>
element, after the last <Cube>
.
Here is an example of a role:
<Role name="California manager"><SchemaGrant access="none"><CubeGrant cube="Sales" access="all"><DimensionGrant hierarchy="[Measures]" access="all"/><HierarchyGrant hierarchy="[Store]" access="custom" topLevel="[Store].[Store Country]"><MemberGrant member="[Store].[USA].[CA]" access="all"/><MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/><HierarchyGrant hierarchy="[Customers]" access="custom" topLevel="[Customers].[State Province]" bottomLevel="[Customers].[City]"><MemberGrant member="[Customers].[USA].[CA]" access="all"/><MemberGrant member="[Customers].[USA].[CA].[Los Angeles]" access="none"/><HierarchyGrant hierarchy="[Gender]" access="none"/></CubeGrant></SchemaGrant></Role>
A <SchemaGrant>
defines the default access for objects
in a schema. The access
attribute can be "all" or "none"; this access can be overridden for specific objects. In this case, because access="none"
, a user would only be able to browse the "Sales" cube, because it is explicitly granted.
A <CubeGrant>
defines the access to a particular cube.
As for <SchemaGrant>
, the access attribute can be "all", "custom" or "none", and can be overridden
for specific sub-objects in the cube.
A <DimensionGrant>
defines access to a dimension.
The access attribute can be "all", "custrom" or "none". An access level of "all" means that all the child hierarchies of the dimension will get inherited access. An access level of "custom" means that the role does not get an inherent access to the child hierarchies,
unless the role is explicitely granted using a <HierarchyGrant> element.
A <HierarchyGrant>
defines access to a hierarchy.
The access attribute can be "all", meaning all members are visible; "none", meaning the hierarchy‘s very existence is hidden from the user; and "custom". With custom access, you can use the topLevel
attribute to define the top level which is visible
(preventing users from seeing too much of the ‘big picture‘, such as viewing revenues rolled up to the Store Country
level); or use the bottomLevel
attribute to define the bottom level which is visible (here, preventing users from
invading looking at individual customers‘ details); or control which sets of members the user can see, by defining nested <MemberGrant>
elements.
You can only define a <MemberGrant>
element if its
enclosing <HierarchyGrant>
has access="custom"
. Member grants give (or remove) access
to a given member, and all of its children. Here are the rules:
topLevel="[Store].[Store State]"
, and grant access to California, you won‘t be able to see USA. Member grants do not override the topLevel
and bottomLevel attributes. You can grant or deny access to a member of any level, but the top and bottom constraints have precedence on the explicit member grants.In the example, the user will have access to California, and all of the cities in California except Los Angeles. They will be able to see USA (because its child, California, is visible), but no other nations, and
not All Stores (because it is above the top level, Store Country
).
标签:设计
原文地址:http://blog.csdn.net/u014723529/article/details/42105377