由于BOE的系统与SAP相比，并不是同一个数量级的，所以权限系统自然不会像SAP那么复杂。另外，BOE的思想与产品目的与SAP也不尽相同，所以权限系统的理念也有少许的出入。
注：此处并不涉及与SAP BW集成的权限问题。
对于BOE的权限系统来说，万事万物皆对象。这里的对象不是面向对象编程的对象，而是在CMC里看到的所有东西，都是一个object，包括本身就是用来控制权限的access level也是，权限控制的最小的粒度就是对象级，也就是设置谁可以访问这个对象，可以如何访问。所以，有一个可能让初学者犯错的就是在user/user group上设置权限，会有人误以为是为这个user/user group设置权限，其实是谁可以有什么样的权限来访问/修改这些user/user group。
OK，既然提到了对象，那么接下来介绍下BOE权限设置的3个层级：
Top level folder
folder
object
由于BOE本质上对终端用户来说是个报表系统，而她们的访问途径是InfoView，里面有各个文件夹，下面是各种报表，所以以Folder的层级方式来控制权限是有一定考虑和道理的。
Top level folder顾名思义，一旦设置了一些权限，所有下面的object都具有了此权限。这里指的是Public Folders
而Folder则细化了一下，是对folder的限制。而Object则在前面已经涉及。所以根绝BO产品特点，这种粒度的权限层级控制已经够用了。权限的具体细化和变化要靠权限的真正控制对象access level以及继承关系。
AccessLevel相当于SAP中的profile。但是在SAP中对权限的控制的理念是我不会设置你不能做什么，默认你什么都不能做，我设置的是你能做什么。在BO中稍有不同，默认也是什么都不可以做，但是却可以设置你可以做什么和明显设置你不能做什么，也就是Deny的操作。这样在有了继承的概念后，可以做一些权限配置上的变化，但是个人认为也复杂化了配置。
在AccessLevel权限控制中，权限会按照以下类别进行组织：
General - 影响全部
Content - 按对象内容，比如PDF,WebI
Application - 按照应用类型，比如WebI DeskI
System - 可以错略理解为CMS中系统服务对象的内容
而每个权限的赋予，又都有一个scope，只不过这个scope很简单：只针对单独的对象还是包含子对象。此处很容易理解，不必费口舌。
而由于有了继承 有了override（子对象对继承而来的权限的覆盖），所以权限必然会变得复杂。BOE提供了2个troubleshooting工具：
Permission Explorer
Security Query
首先，Permission Explorer是用来帮助管理员找到一个user/user group对某个对象拥有的访问的权限来源是哪里。
这在有很多继承关系的时候有为有用。
如上图，我们找到了view object这个right的来源：继承自Everyone在Root Folder的accessLevel view
而Security Query则用来测试一个用户是否具有某个权限或者有哪些权限。
如图，我想看Administrator在Folder这个层级或者说这个Object的语境下，对哪些对象有添加对象到Folder的权限。
- 查看图片附件