针对于集团应用系统的数据权限控制

CshBBrain 2010-12-24

针对于集团应用系统的数据权限控制
系统中的组织机构介绍：系统中有多个集团，每个集团下有多个公司以及公司，每个公司下又有多个直属部门和办事处，办事处下面又有多个部门
业务往来关系：1个集团下的公司，分公司相互之间存在业务往来；当然公司下的部门之间，办事处之间，以及办事
处下的部门之间肯定是存在相互业务往来的，比如财务部门要计算工资，必须需要人力资源部的考勤数据和专业部门的奖励惩罚数据等；公司之间的部门
亦可存在相互业务往来，集团部门和各公司部门之间亦存在业务往来，
比如各公司分公司的人力资源部门和集团人力资源
存在业务往来，集团人力资源对集团内的人力资源做整体上的规划，监督，考核执行，而各公司分公司人力资源部门执行各公司的人力资源管理工作，其他专业体
系也具有类似架构；
集团和各公司，分公司存在业务往来； 1个集团和其他多个集团可能存在业务上的往来；集团下的公司，分公司与系统中的其他集团中的公司，
分公司存在业务往来，
比如A集团下的a公司有个工程承包给B集团的b公司负责建设，a公司的对应部门需要对b公司的工程进度，质量等等监督。

根据描述系统中的业务往来就成了一个业务网，业务复杂；而数据权限的控制也是一个头痛的事情：
数据权限通用规则：
对于一般用户来说：
1.有些数据是行业标准，系统中的所有集团中的所有用户多可以查看和维护。
2.有些数据是某个集团内部所有用户都可以查看维护。
3.有些数据是只有某个公司内部的所偶有人可以维护查看。
4.有些数据是只有某个部门下的所有人可以查看维护。
5.还有一些数据只有这个数据的拥有人才可以查看维护。

不同于有些特权用户（不管你这个功能的数据权限怎样控制）的权限规则：
1.某些用户可以查看维护集团内的所有数据。
2.某些用户可以查看维护公司内部的所有数据
3.某些用户可以维护查看某个部门的所有数据
4.某些用户可以查看维护其他一些公司，一些部门的数据。
5.有些用户可以维护其他集团中某些公司，某些部门的数据。

这样的数据权限控制系统怎样设计呢？希望有这方面设计经验的朋友建议下。

CshBBrain 2010-12-25

这么冷清呀，我先说说自己的考虑吧，希望能起到抛砖引玉的作用：
1.系统肯定提供菜单功能注册管理的功能，且细化到功能按钮级别（增删改查），每个菜单功能都设计一个【数据权限控制策略】，分为系统控制级：系统中所有用户都可以维护，集团控制级别：集团内所有用户都可以维护，公司分公司级别：公司分公司中的所有用户都可以维护，部门级别：部门内所有用户都可以维护，用户级别：只有数据的创建人可以维护。
2.数据权限和具体部门下的角色也有很大的关系，所以系统中少不了角色；给每个角色设计一个【数据权限控制策略】，分为系统控制级：可以维护系统中所有数据，集团控制级别：可以维护集团内所有数据，公司分公司级别：可以维护公司分公司内的所有数据，部门级别：可以维护部门内所有数据。
3.另外为了解决无规则的数据权限控制需求，设计一个针对部门下面的角色和人的数据权限授予功能，可以在这里指定角色或人能维护哪些组织机构单元中的数据（本来打算使用这一种方式处理所有权限控制，但考虑到系统管理员授予数据权限的工作量太大，系统管理员非常抵制这种做法）。
4.数据权限的过滤技术需要使用到AOP拦截器,过滤器以及权限数据的缓存，将某次查询的数据过滤条件附件到具体的查询条件上，好了，这里先抛开具体的实现技术和方法。
5.数据权限计算规则：
5.1如果此菜单功能的【数据权限控制策略】为系统级别，好说，不做任何数据过滤。
5.2如果此菜单功能的【数据权限控制策略】为集团级别，则如果当前访问用户的角色的【数据权限控制策略】为系统级别，则不做任何数据过滤；如果当前访问用户的角色的【数据权限控制策略】为集团级别以及更低的级别，则不用户可以访问其所在集团的所有数据 + 授予给此角色或用户的特殊数据权限。
5.2如果此菜单功能的【数据权限控制策略】为公司级别，则如果当前访问用户的角色的【数据权限控制策略】为系统级别，则不做任何数据过滤；如果当前访问用户的角色的【数据权限控制策略】为集团级别，则不用户可以访问其所在集团的所有数据 + 授予给此角色或用户的特殊数据权限。如果当前访问用户的角色的【数据权限控制策略】为公司级别以及更低的级，则当前用户可以访问其所在公司的所有数据 + 授予给此角色或用户的特殊数据权限。
依次类推。。。。。。。。

但客户还是觉得麻烦，有没有更简单的方案呢

javamonkey 2010-12-27

说的挺好的呀，需求本来就是这样，为啥客户觉得麻烦了？。

我觉得你可以给客户简化表达一下你的意思：数据资源与角色关联，数据访问层使用过滤技术就行了吧。

我猜是你把需求和设计混在一起说了吧，客户觉得内容太多？

kurier 2011-01-06

我觉得使用默认权限+特殊权限的方式是会增加复杂度。
统一解决就好了，客户也好理解些

yongtree 2011-01-20

数据权限有必要跟功能菜单绑定吗？
是不是可以单独定义。

yongtree 2011-01-20

数据权限是不是要用组织结构中的岗位来控制，角色控制功能权限。如果全部用角色控制，会使角色太多。
http://blog.csdn.net/lijj_72/archive/2008/12/13/3510881.aspx

xieliankang 2011-03-18

个人觉得这一类业务需求的本质就是什么人可以做什么事（功能菜单），不防从下面几个角度来考虑：
1.公司：集团与分公司之前的关系
2.部门：公司内容部门，即组织架构
3.角色：部门相关，至少是公司相关
4.角色类型：公司无关，针对整个集团
结合功能菜单设置权限：
查看、编辑、管理；
对应人员关联：按公司，按部门，按角色，按角色类型。

w412692660 2011-03-24

首先,顶上,回答一下试试,当然,一样是粗陋不堪的设计,抛砖引玉,不过问题确实很好;
我从三个方面来回答,
第一个方面,是从我如果在现实项目中遇到,如何去做,一般是保守的做法,估计没有特别新奇的东西,都是些老土概念和做法,重点稳定;
第二个方面,是用楼主的思维去作出设计,然后,去说说优缺点,这样设计我也做过,是在一个简单资源管理系统,当时由于是简单用户权限,直接用角色->功能,这个当然和楼主思想有些差异,不过有仔细看过楼主
的言论,到时有叙述错误的地方,还请纠正;
第三方面,属于个人突发奇想..就是那种一拍脑袋想出来的...哈.不敢用于项目中,因为怕有意想不到的问题蹦出来,哈哈,这个纯属实验性的解决方案;

好,我们从第一个方面来说:

我是从数据库表+领域模型来说这个事情,
首先,我们组织结构设计方法有很多,但是总体来说一般就是万能型和业务型,万能型就是用户->用户组那一套,业务就是根据业务来设计,当然业务负责选择业务来设计是很OK的,
在第一方面里,我们使用业务主键来设计,在第二,三方面,我们会换其他的设计,哈,一个一个来,因为行业项目业务复杂的,一般我都会用业务主键,当然是某些地方是混用的;

具体就不写具体属性啦,这是初步的组织结构;
我们要解决的问题,其实是两个问题 :人员的权限,内容,我们用此来建立领域模型;

内容:我在内容建模时,只想一般用户,我们只为一般用户服务,OK;
人员权限:是非正常的特权;
注:这里我看楼主叙述时,没有将查看与维护的权限分类,这么我们就将查看与维护合并,当然如果查看与维护分离设置,可能设计时会有部分不同,至少比现在的设计多张表;

内容的领域模型:

为人的权限建模:

最后设计出来的表:

企业基本信息:

组件权限管理:

内容信息管理:

这样的话,就可以正常走[内容管理]可以,因为从创建人就可以定义的他可以制定的内容级别范围,从而创建人自由设定设定发布内容的权限
走特权的人,走授权策略路线,查询时先查询是否是特权用户或者特权部门,特权是可以配置的,所以可以临时;
这样管理员只需要配置特权的人就OK,或者临时特权;

这是从数据库表,定义出结构,不知道明白没有,不知不觉写了这么多.......
结果只写第一个方面,明天在写第二方面....哈哈,有不妥当的地方还望指出..纯属抛砖!

凤舞凰扬 2011-03-31

楼上的截图都已经失效了，建议啊，先把图片存放在本地，再使用。

w412692660 2011-04-03

.....OK,一直不知道,可以有上载图片的功能

发表回复

>>返回群组首页

针对于集团应用系统的数据权限控制

相关讨论

相关资源推荐