Pentaho Cube权限设置
2014-12-23 17:27
274 查看
简单的分为两步:
1、Pentaho中配置角色
2、Cube中增加Role
配置角色:
![](http://img.blog.csdn.net/20141223172821246?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxNDcyMzUyOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
Cube中增加Role
![](http://img.blog.csdn.net/20141223172839654?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxNDcyMzUyOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
附上官方文档配置中的Cube设计
children of the
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>
<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>
<HierarchyGrant hierarchy="[Gender]" access="none"/>
</CubeGrant>
</SchemaGrant>
</Role>
A
in a schema. The
A
As for
for specific sub-objects in the cube.
A
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
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
(preventing users from seeing too much of the 'big picture', such as viewing revenues rolled up to the
invading looking at individual customers' details); or control which sets of members the user can see, by defining nested
You can only define a
enclosing
to a given member, and all of its children. Here are the rules:
Members inherit access from their parents. If you deny access to California, you won't be able to see San Francisco.
Grants are order-dependent. If you grant access to USA, then deny access to Oregon, then you won't be able to see Oregon, or Portland. But if you were to deny access to Oregon, then grant access to USA, you can effectively see everything.
A member is visible if any of its children are visible. Suppose you deny access to USA, then grant access to California. You will be able to see USA, and California, but none of the other states. The totals against USA will still reflect
all states, however. If the parent HierarchyGrant specifies a top level, only the parents equal or below this level will be visible. Similarly, if a bottom level is specified, only the children above or equal to the level are visible.
Member grants don't override the hierarchy grant's top- and bottom-levels. If you set
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,
1、Pentaho中配置角色
2、Cube中增加Role
配置角色:
Cube中增加Role
附上官方文档配置中的Cube设计
9.1 Defining a role
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>
<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>
<HierarchyGrant hierarchy="[Gender]" access="none"/>
</CubeGrant>
</SchemaGrant>
</Role>
A
<SchemaGrant>defines the default access for objects
in a schema. The
accessattribute 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
topLevelattribute 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 Countrylevel); or use the
bottomLevelattribute 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:
Members inherit access from their parents. If you deny access to California, you won't be able to see San Francisco.
Grants are order-dependent. If you grant access to USA, then deny access to Oregon, then you won't be able to see Oregon, or Portland. But if you were to deny access to Oregon, then grant access to USA, you can effectively see everything.
A member is visible if any of its children are visible. Suppose you deny access to USA, then grant access to California. You will be able to see USA, and California, but none of the other states. The totals against USA will still reflect
all states, however. If the parent HierarchyGrant specifies a top level, only the parents equal or below this level will be visible. Similarly, if a bottom level is specified, only the children above or equal to the level are visible.
Member grants don't override the hierarchy grant's top- and bottom-levels. If you set
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).
相关文章推荐
- XP下设置共享文件夹的权限
- 求助:LAN中如何设置域用户的权限
- 通过试验探索 Access 2000/XP 数据库的最佳 NTFS 权限设置 (转)
- Windows下权限设置详解
- mysql设置权限
- 不基于NTFS权限的CVSNT权限设置
- ASP.NET在使用Access数据库的IIS和目录权限设置
- [Windows安全设置]Windows下权限设置详解
- (转载)Windows下权限设置详解
- 权限设置问题!(比较着急)
- 不基于NTFS权限的CVSNT权限设置
- windows2000虚拟主机基本权限设置
- 木马、病毒防范之注册表权限设置法
- MySQL中文参考手册7(MySQL 存取权限系统) grant 设置密码 password
- 通过试验探索 Access 2000/XP 数据库的最佳 NTFS 权限设置
- 关于VSS系统权限设置
- 权限设置的问题
- WIN2000下CVS不同用户设置不同的访问权限方法
- 简单突破权限设置漏洞挂马
- CVS权限设置