Pentaho Cube权限设置

简单的分为两步:

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>

<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.

<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.

<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.

<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 Countrylevel); 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:

  1. Members inherit access from their parents. If you deny access to California, you won‘t be able to see San Francisco.
  2. 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.
  3. 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.
  4. 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).

时间: 2024-08-06 16:00:58

Pentaho Cube权限设置的相关文章

MongoDB学习之权限设置详解

MongoDB数据库是一个基于分布式文件存储的数据库,为目前主流的NoSQL数据库,已被应用到许多高性能的大型系统中.如果之前从未接触MongoDB,可以访问 MongoDB官网 快速了解其主要特性及应用场景. MongoDB的安装 此文示例的环境基于CentOS 7.3 64位,MongoDB版本为3.2.4. 1. 在服务器上,以超级用户权限执行yum安装,命令如下: [[email protected]]# su [username] -- username 为你登陆服务器的用户名[[em

SVN单独用户具有某个文件夹的单独权限设置

项目要求:       修改guest用户只能对项目的 code 文件下的内容具有 r (读)的权限 设置办法: 在浏览器中访问 svn://XXX 1.权限设置之前(rw)用户之前预览        ? 2.进行设置 编辑 ../conf/authz 文件   # vim authz 这样设置即可,SVN不用重启就会生效 3.设置后进行验证测试 浏览器中访问 svn://XXX/flight/trunk/code 即可实现 guest 用户对 code 文件只有只读的权限,其他文件到看不到 遗

Linux运维六:用户管理及用户权限设置

Linux 系统是一个多用户多任务的分时操作系统,任何一个要使用系统资源的用户,都必须首先向系统管理员申请一个账号,然后以这个账号的身份进入系统.用户的账号一方面可以帮助系统管理员对使用系统的用户进行跟踪,并控制他们对系统资源的访问:另一方面也可以帮助用户组织文件,并为用户提供安全性保护.每个用户账号都拥有一个惟一的用户名和各自的口令.用户在登录时键入正确的用户名和口令后,就能够进入系统和自己的主目录. 实现用户账号的管理,要完成的工作主要有如下几个方面: · 用户账号的添加.删除与修改. ·

winform(MDI窗体容器、权限设置)

一.MDI窗体容器: 1.功能: 它可以让其它窗体在它的内部打开,无法超出它的范围 将某个窗体的属性:IsMdiContainer设置为true - 窗口样式 2.问题: (1)如何将其它窗体在它的内部打开? 窗体对象名.MdiParent = this; (2)窗体打开时最大化属性不好用,怎么办? 在实例化窗体对象,show之前,用代码设置最大化属性 注意:窗体的WindowState属性必须为默认值Normal (3)内部窗体最大时右上角总是显示最大最小关闭按钮,如何去掉? 在MDI窗体里放

文件/目录权限设置命令chmod的详细用法

chmod是文件/目录权限设置的命令,在Linux中经常遇到,本博文以下总结chmod的详细用法. Linux/Unix的档案调用权限分为三级,即档案拥有者user.群组group.其他other.u表示该档案的拥有者,g表示与该档案的拥有者属于同一个群体(group)者,o表示其他以外的人,a表示这三者皆是. + 表示增加权限.- 表示取消权限.= 表示唯一设定权限. r表示可读取,w表示可写入,x表示可执行. 举例说明: (1).将档案file1.txt 设为所有人皆可读取: chmod u

RDIFramework.NET 框架之组织机构权限设置

RDIFramework.NET 框架之组织机构权限设置 对于某些大型的企业.信息系统,涉及的组织机构较多,模块多.操作权限也多,对用户或角色一一设置模块.操作权限等比较繁琐.我们可以直接对某一组织机构进行权限的设置,这样设置后,同一组织机构的用户就可以拥有相应的模块访问权限,操作权限了,这样也能减轻管理人员的负担.要启用组织机构权限,需要配置Config.xml配置节"EnableOrganizePermission"为True.要打开组织机构权限设置,我们需要选择"系统管

Linux 权限设置

一.文件和目录权限 在Linux系统中,用户可以对每一个文件或目录都具有访问权限,这些访问权限决定了谁能访问,以及如何访问这些文件和目录. 1.文件权限简介 在Linux系统中,每一位用户都有对文件或目录的读取.写入和执行权限.第1套权限控制访问自己的文件权限,即所有者权限.第2套权限控制用户组访问其中一个用户的文件的权限.第3套权限控制其他所有用户访问一个用户的文件的权限.这3套权限赋予用户不同类型(即所有者.用户组和其他用户)的读取.写入及执行权限. 2.一般权限 用"ls -l"

linux 用户权限设置

# useradd –d /usr/sam -m sam 此命令创建了一个用户sam,其中-d和-m选项用来为登录名sam产生一个主目录/usr/sam(/usr为默认的用户主目录所在的父目录). 假设当前用户是sam,则下面的命令修改该用户自己的口令: # passwd Old password:****** New password:******* Re-enter new password:******* 如果是超级用户,可以用下列形式指定任何用户的口令: # passwd sam New

PSSecurityException之PowerShell权限设置

Windows下PowerShell默认的权限级别是Restricted,不允许执行PS脚本(即.ps1文件).如果在Restricted权限级别下运行,会得到错误信息: .\XXXX.ps1 : File XXXX.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at http://go.micr