RBAC (Role based Access Control) 基于权限的访问控制
在R12.2 之后，EBS引入了Role的概念，相较于以前通过Responsibility来控制用户的访问权限的方式外，引入了Role的方式给用户分配访问权限
下面介绍几个Role的使用方法
通过Role实现同一个Responsibility下不同Role的有不同的功能访问权限
- 新建一个Menu，分配需要子菜单1 和子菜单2 ，菜单下所有子菜单的授权全部不勾选
- 新建一个Responsibility X，关联新建的菜单
- 新建一个Role A，然后继承自Responsibility X，然后给这个Role创建授权，授权的permission set为菜单中的子菜单1。
- 新建一个Role B，然后继承自Role A，然后给这个Role创建授权，授权permission set为菜单中的子菜单2。
只分配了Role A的用户，就可以看到Responsibility X，但是只能访问菜单1
这样只分配了Role B的用户，就可以看到Responsibility X，可以访问菜单1和菜单2
相应的配置文件还是在Responsibility层设置。
通过套娃的方式可以方便设置。标准功能可以参考Approval Manager Administrator的设置。
通过Role/Grant实现针对某个用户分配请求权限
- 新建一个role，然后创建授权
- 同时可以限定职责，如果不限定则在所有职责都可以提交
- 数据安全性选择并发程序，在数据上下文中指定对应的请求信息。
分配了这个role的用户就可以提交这个请求。这样可以避免Request Group无法针对用户限制某些报表的问题
Fusion的权限
Fusion的权限完全基于Role，还去掉了Responsibility的概念。对于权限管理带来了一些问题
- Role授权功能的最小单位是Permission Set，也就是子菜单。由于默认子菜单无法新增/调整，会存在子菜单中部分Function无法被排除
- 完全基于Role来分配Function和Data Security，没有Responsibiltiy的上下文，会出现Update/View Only权限无法在同一个功能上区分。但是在网页界面继续保留Responsibility，好像也有点丑。。。
