⼀、数据权限定义
数据权限主要分为维护权限，使⽤权限，特殊权限。
操作是与业务实体相关联的业务⾏为，分为维护类操作和使⽤类操作。
A. 维护类操作：对业务实体数据进⾏维护，改变其属性的操作，例如删除、修改等。
B. 使⽤类操作（使⽤场景）：不改变业务实体数据的属性，只是引⽤业务实体数据的操作，例如参照，引⽤等。
NC6.0系统中对数据权限做了重⼤调整，对资源实体做了扩充，引⼊了权限规则，操作等概念，模型概念图如下图所⽰： ⼆、数据权限规则
⽬前NC6.0数据权限采⽤禁⽌权优先的原则，例如⼀旦⽤户所在的⾓⾊有⼀个设置了⽆权那么他就没有操作的权限。如果特殊权限和维护权限都配置了，则依然采⽤禁⽌权优先的原则。
NC6.0数据权限按照使⽤的场景，分为维护权限和使⽤权限两部分，维护数据权限是指对某种资源实体的数据有⽆增删改查的权限，典型的应⽤场景包括对某条单据进⾏修改操作或者删除操作时，校验当前⽤户是否有权限进⾏这项操作。
⽽使⽤权限则是指在资源实体被引⽤到某个场景的时候，对当前⽤户的限制，换句话说就是控制⽤户对某资源实体的数据引⽤查看校验。
维护权限使⽤权限
应
⽤
场
景
修改，删除等操作查询，参照过滤等
授予类型的权限，如果某⾓⾊对某资源不设置维护数据权限，则认为该⾓⾊对这个资源有权限制类型的权限，如果某⾓⾊对某资源不设置使⽤数据权限，则认为改⾓⾊对这个资源有权
可在不同的⾓⾊下定义不同的维护权限规则可在不同的⾓⾊下定义不同的使⽤权限规则
分为两级：粗粒度级规则即(全部有权或者合部⽆权)；细粒度规则(指可以对元数据上的每个字段进⾏权限的控制)分为两级：粗粒度级规则即(全部有权或者合部⽆权)；细粒度规则(指可以对元数据上的每个字段进⾏权限的控制)乳鸽养殖
特殊权限与数据权限是Or关系，但是采⽤禁⽌权优先原则
三、规则控制组合
3.1不需执⾏后台任务⽣效的
1.⽤户关联⼀个⾓⾊，定义规则，全部有权，全部⽆权均应控制正确；⾓⾊未定义规则，即未启⽤数据权限，控制结果集为全部
2.⽤户关联两个⾓⾊，两个⾓⾊均定义使⽤权限规则，控制结果集取两个规则的合集
3.⽤户关联两个⾓⾊，⼀个⾓⾊定义规则，⼀个⾓⾊不定义规则，控制结果集为按规则控制
4.⽤户关联两个⾓⾊，⼀个⾓⾊定义规则，⼀个⾓⾊全部有权，控制结果集为全部有权有机硅单体
5.⽤户关联两个⾓⾊，⼀个⾓⾊定义规则，⼀个⾓⾊全部⽆权，控制结果集为全部⽆权（即使⽤户关联多个⾓⾊，只要有⼀个是全部⽆权，控制结果集便为全部⽆权）
6.为某个已关联⽤户的⾓⾊增加规则
7.修改规则，由规则A修改为规则B，按更新后的新规则控制电路板测试台
8.修改规则，由规则A修改为全部⽆权，所有关联该⾓⾊的⽤户全部⽆权
9.修改规则，由规则A修改为全部有权
9.修改规则，由全部有权修改为全部⽆权
9.删除规则（注：因为删除规则会带来权限分表的删除，通知到前台缓存会有2-3分钟的等待时间） 10.为某个未启⽤数据权限的⾓⾊启⽤数据权限（特别关注⽤户关联多⾓⾊，其中某个⾓⾊未启⽤数据权限，然后为其启⽤数据权限，定义规则），按规则控制
11.将某⾓⾊下的所有规则删除，（特别关注⽤户多⾓⾊场景）
12.取消⽤户与⾓⾊的关联关系，曾经⾓⾊的规则不在起作⽤
13.⽤户共享与调动
⽤户由A集团共享⾄B集团，在A，B集团均启⽤数据权限，各个集团内的控制结果正确
⽤户由A集团调动到B集团，在A，B集团均启⽤数据权限，A集团的权限取消，B集团控制正确
3.2、需定义执⾏后台任务“权限有效期及数据变更调整定时任务”
14.符合规则的数据集中档案的增加；（如定义客户的使⽤权限规则为：客户分类=A，在分类A中增加客户档案add1，需执⾏完后台任务才可在参照中参照到add1）
15.⽤户关联⾓⾊到达⽣效⽇期与失效⽇期
3.3场景的说明
1.产品出⼚时，若产品领域有预置场景，则产品下各单据起数据权限的字段默认⾛产品领域的预置场景；没有预置场景的产品单据，起数据权限的字段默认⾛通⽤引⽤场景
（已测试通过，以物料采购分类为例）
2.可扩展单据字段适⽤的场景范围（元数据管理节点）
四、数据维护权测试要点
4.1、维护数据权限规则
同上述数据权限测试要点中规则控制
4.2、维护权的组合
--禁⽌权优先，（禁⽌权中包含创建者⽆权，全部⽆权），其余为合集
五、数据权限分表⽬前有两种机制
1.可及时⽣效的分表任务
2.通过定义后台任务执⾏的分表任务
5.1、可及时⽣效的分表任务
⽤户关联⾓⾊；
取消关联关系；
为⽤户关联的某个⾓⾊增加使⽤权限规则；
删除某⾓⾊某场景下的规则；
规则的变动（如编辑规则，由规则改为全部有权或全部⽆权等）
……
5.2、通过后台任务执⾏的分表任务
符合规则的数据集中档案的增加；（如定义客户的使⽤权限规则为：客户分类=A，在分类A中增加客户档案add1，需执⾏完后台任务才可在参照中参照到add1）
5.3、分表任务的验证
1.分表的纬度为：⽤户，资源实体，场景，集团
2.表的创建时机：在⾓⾊分配完规则会去计算， 如果⾓⾊关联了⽤户产⽣分表，未关联不产⽣分表
为⽤户分配⾓⾊会去计算分表。 如果⾓⾊定义了数据权限 则能产⽣分表，未定义不分表
3.表的删除时机：某⽤户在⼀个集团内，在某个资源实体，某个场景下已没有规则，则删除相应的分表。（可通过取消⽤户⾓⾊的关联关系；删除⾓⾊的权限规则来实现。）
5.4、验证步骤建议
库中查询分表数据的SQL语句：select* from sm_dpprofile_reg where cuserid='10021110000000000HIH' （查询某⽤户的分表任务，其中cuserid可以通过⽤户表sm_user查询出）
在这张表⾥可以查询出⽣成的分表名，资源实体，场景和集团
1.U1关联RA1（⾓⾊若定义了规则，则按照⽤户+资源实体+场景+集团的维度⽣成表）
2.若⽤户+资源实体+场景+集团下已没有规则，则删除表；若还有规则，则按照新规则计算结果更新表内容（删除规则，删除⽤户与⾓⾊的关联关系）
3.⽤户关联多个⾓⾊，仍按照⽤户+资源实体+场景+集团的维度⽣成表，若依照该维度已经存在有表，则表不变，按照新规则计算结果更新表内容）
4.共享⽤户，保留原集团内表，按照⽬的集团内规则再⽣成表
5.⽤户调动，共享集团B的表⽆变化，源集团A集团的表被删除
6.⽤户停⽤，权限被清空，表被删除
六、数据权限参数设置
使⽤系统管理员登录环境，
【应⽤系统管理】-【系统初始化】-【系统参数设置】
按照⽤户—资源实体的模式进⾏分表，把资源实体对应的具体数据的ID存储在分好的表中。
由于规则数据分表存储是⼀个后台的异步任务，所以在规则设置之后并不是⽴即⽣效的，需要等待⼀段时间之后才能够⽣效，通常有三种模式需要重算规则数据。
1． ⽤户重新委派⾓⾊
2． ⾓⾊的权限设置发⽣变化
3． 档案数据发⽣变化。
由于前两个和我们关系不⼤，我们只关⼼最后⼀个我们⾃⼰档案⼀旦发⽣数据变化应该如何处理。
现⾏的数据使⽤权，是采⽤数据库分表来记录符合条件的数据。当对应的档案数据发⽣变化时，也需要重新运算分表结果。
为了解决这两个问题，权限模块提供了⼀个后台任务，任务名称为“权限有效期及数据变更调整定时任务”。此定时任务在实施时启动，建议
每天执⾏⼀次，在每天凌晨00：05：00执⾏。它将处理前⾯提到的两个问题。
为了能够让权限系统知道档案数据发⽣了变化并进⾏变化记录，需要⽀持使⽤权限的档案，当数据发⽣变化时(新增后、修改后、删除后)，发送
业务事件。默认规定事件源ID即为档案数据对应元数据实体的ID（即定义的权限实体资源所关联的元数据ID），事件类型为：
IEventType.TYPE_INSERT_AFTER新增后； IEventType.TYPE_UPDATE_AFTER 修改后；IEventType.TYPE_DELETE_AFTER删除后。
传输事件对象为：nc.bs.businessevent.UsePermChangeEvent。平台注册的监听会收集上述事件并记录数据变化。当发⽣数据变化时，调⽤
EventDispatcher.fireEvent(newUsePermChangeEvent(mdid, ))。
第⼀步：部署后台任务
注册插件（UAP注册）这⾥需要说明的是这个事件是全局的只要发送新增后 修改后 删除后都会⾛这个监听。
insertinto pub_eventlistener (dr, enabled, implclassname, name, note, operindex,owner, pk_eventlistener, pk_eventtype, ts) values (0, 'Y','nc.bs.rbac.bizlistener.BaseDocDataPermChangeEventListener', '档案数据权限分表任务插件', '数据使⽤权限分表任务', 99, '1012', '1001ZZ10000000016F0A','1001ZZ10000000016F09', '2011-04-28 16:57:24');
insertinto pub_eventtype (dr, eventtypecode, eventtypename, note, owner,pk_eventtype, sourceid, sourcename, ts) values (0, '1002', '数据使⽤权限分表_档案新增后', '新增档案之后，数据权限分表任务关⼼档案的新增事件，对已经进⾏数据权限分配的档案，要进⾏数据权限分表任务调度，将分表中的记录进⾏更新', '10','1001ZZ10000000016F09', 'ALL', '所有档案', '2011-04-28 16:56:04');
注意：由于档案⾃⾝可能会有⼀些业务单据对其进⾏新增后，修改后，删除后进⾏监听，所以我们要在其他监听类加上如下代码
元数据类型：
元数据类型规则编辑器
三相四极插头规则编辑器： nc.ule.impl.MetaDataRuleEditor
规则⽣成⼯⼚： nc.ule.impl.MetaDataRuleFactory
联络开关离散类型：
离散树型编辑器
规则编辑器：nc.ui.uap.rbac.rule.discret.ZDiscretDataTreeRuleEditor
规则⽣成⼯⼚：nc.uap.rbac.rule.discret.DefaultDiscretRuleFactory
乙烯乙二醇离散表规则编辑器
规则编辑器：nc.ui.uap.rbac.rule.discret.DiscretDataTableRuleEditor
规则⽣成⼯⼚：nc.uap.rbac.rule.discret.DefaultDiscretRuleFactory
权限分表介绍：
数据权限的使⽤权⽬前主要涉及两种⽅式，⼀种是在参照中加⼊使⽤权控制。⼀种是⽤户调⽤权限接
⼝获得关⼼档案的使⽤权规则sql条件。 在开发使⽤过程中，这两种情况的发⽣率都是很⾼的。如果每次都去集合⽤户所有的⾓⾊对关⼼档案所定义的数据权限使⽤权规则，然后根据规则⽣成⼀条复杂的sql条件提供给参照或者开发者。参照或者开发者再连接到⾃⼰的查询条件后，再去查询⾃⼰需要的数据，这样势必造成效率问题和sql的复杂度的升⾼。
为了解决这个问题，为每个定义了使⽤权规则的档案或者单据建⽴⼀个分表。此表中仅有id⼀个字段，
⽤于存储能唯⼀标识业务实体数据的列值。这样权限接⼝提供给开发者的sql条件变为了 “pk in (select id fromzdp_xxxxxxx)”简单语句。
⼋、测试要点：
1、数据权限⽣效机制
1.可及时⽣效的分表任务
n ⽤户关联⾓⾊；
n 取消关联关系；
n 为⽤户关联的某个⾓⾊增加使⽤权限规则；
n 删除某⾓⾊某场景下的规则；
n 规则的变动（如编辑规则，由规则改为全部有权或全部⽆权等）
2.通过定义后台任务执⾏的分表任务
符合规则的数据集中档案的增加；（如定义客户的使⽤权限规则为：客户分类=A，在分类A中增加客户档案add1，需执⾏完后台任务才可在参照中参照到add1）
2、基础数据(参照、查询以及快速查询)
参照查询：只能参照到权限规定内的可使⽤的数据
3、单据的分单、整单、空值
Ø 分单：( 拉式)
⼀张采购订单的单据，包含2条属于不同分类的物料
当采购⼊库单引⽤采购订单时，只能看到规则内的值(数据权限定义有权限的物料分类下的物料)
Ø 整单：(推式)
⼀签字就⽣成下游单据，这时整单据的表体内容都会⽣成
4、关联关系以及跨组织参照
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议