OA 系统权限管理设计方案
数据库
2010-02-23 10:09:25
阅读
13
评论
0
字号：大中小
OA
系统权限管理设计方案
l
不同职责的人员，对于系统操½的权限应该是不同的。优秀的业务系统，这是最基本的功
½。
l
可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工
逐一分配系统操½权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进
行操½的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
l
权限管理系统应该是可扩展的。它应该可以加入到任½带有权限管理功½的系统中。就像
是组件一样的可以被不断的重用，
而不是每开发一套管理系统，
就要针对权限管理部分进行
重新开发。
l
满足业务系统中的功½权限。传统业务系统中，存在着两种权限管理，其一是功½权限的
管理，而另外一种则是资源权限的管理，在不同系统之间，功½权限是可以重用的，而资源
权限则不½。
针对
OA
系统的特点，权限说明：
权限
+
在系统中，权限通过模块+动½来产生，模块就是整个系统中的一个子模块，可½对应一个
菜单，动½也就是整个模块中（在
B/S
系统中也就是一个页面的所有操½，比如“浏览、添
加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。
权限组
为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就
是一个模块管理权限，包括所有基本权限操½。比如一个权限组（用户管理），包括用户的
浏览、添加、删除、修改、审核等操½权限，一个权限组也是一个权限。
角色
权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，
用于方便权限的分配。
用户组
将某一类型的人、具有相同特征人组合一起的集合½。通过对组授予权限（角色），快速½
一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按
职½、项目或其它来实现。用户可以属于某一个组或多个组。
通过给某个人赋予权限，有
4
种方式(参考飞思办公系统)
A.
通过职½
a)
在职½中，职½成员的权限继承½前所在职½的权限，对于下级职½拥有的权限不可继
承。
b)
实例中：如前台这个职½，对于考勤查询有权限，则可以通过对前台这个职½设½考勤
查询的浏览权，½他们有½用这个对象的权限，然后再设½个，考勤查询权（½然也可以不
设½，默认½进此模块的就½查询），则所有前台人员½拥有考勤查询的权利。
B.
通过项目
a)
在项目中，项目成员的权限来自于所在项目的权限，他们同样不½继承下级项目的权限，
而对于项目组长，他对项目有全权，对下级项目也一样。
b)
实例中：在项目中，项目成员可以对项目中上传文档，查看本项目的文档,可以通过对项
目设½一个对于本项目的浏览权来实现进口，
这样每个成员½访问这个项目了，
再加上项目
文档的上传权和查看文档权即可。
c)
对于组长，因为可以赋予组长一个组长权（组长权是个特殊的权限，它包含其他各种权
限的一个权限包） 所有组长对于本项目有全权，
，
则项目组长可以对于项目文档查看，
审批，
删除，恢复等，这些权限对于本项目的下级项目依然有效。
C.
通过角色
a)
角色中的成员继承角色的权限，角色与角色没有上下级关系，他们是平行的。通过角色
赋予权限，是指没办法按职½或项目的分类来赋予权限的另一种方式，如：系统管理员，
资
料备½员…
b)
实例中：对于本系统中，全½人员应该默认½有的模块，如我的邮件，我的文档，我的
日志，我的考勤……，这些模块系统成员½应该有的，我们建立一个角色为系统默认角色，
把所有默认访问的模块的浏览权加入到里面去，则系统成员½½访问这些模块。
D.
直接指定
a)
直接指定是通过对某个人具½指定一项权限，½其有½用这个权限的½力。直接指定是
角色指定的一个简化版，
为了是在建立像某个项目的组长这种角色时，
省略创建角色这一个
步骤，½角色不至于过多。
b)
实例中：指定某个项目的组长，把组长权指定给某个人。
针对职½、项目组：
如果用添加新员工，员工调换职½、项目组，满足了员工会自动继承所在职½、项目组的权
限，不需要重新分配权限的功½。
用户管理
用户可以属于某一个或多个用户组，
可以通过对用户组授权，
来对组中的所有用户进行权限
的授予。一个用户可以属于多个项目组，或担任多个职½。
授权管理
将一个基本权限或角色授予用户或用户组，
½用户或用户组拥有授予权限的字符串，
如果角
色、职½、项目中存在相同的基本权限，则取其中的一 个；如脱离角色、职½、项目组，
只是取消用户或用户组的中此角色、职½、项目组所授予的权限。用户所拥有的权限是所有
途径授予权限的集合。管理员用户可以 查看每个用户的最终权限列表。
权限管理
基本操½权限与权限组（基本操½权限的集合）的管理。
OA
权限管理设计的实现
物理数据模型图如下：
物理数据模型图
根据以上设计思想,权限管理总共需要以下基本表：
tb_User：用户信息基本表；
tb_Department：部门表；
tb_Company：公司表；
tb_Module：系统模块表；
tb_Action：系统中所有操½的动½表；
tb_Permit：由 tb_Module
与
tb_Action
两表结合产生的系统基本权限表；
tb_Permit_Group：权限组表，将一模块的中的所有权限划分一个权限组中，可以通过权限
组授予用户权限；
tb_Role：角色表，基本权限的集合。无上级与下级之分；
tb_Position：职½表，有上级与下级之分；
tb_Project：项目组表，
tb_Role_Permit：角色授权表；
tb_Postion_Permit：职½授权表；
tb_Project_Permit：项目授权表；
tb_Project_User：项目成员表，IsLead
字段代表此成员为项目组长；
tb_Postion_User：职½成员表；
tb_User_Permit：用户授权表，用户 ID
与角色、职½、项目及直接授予的权限串表；
权限的产生：
由
tb_Module
中的
ModuleCode
与
tb_Action
中的
ActionCode
组成
权限代码
PermitCode=ModuleCode+ActionCode。
实例：ModuleCode=0101，ActionCode=01,则
PermitCode=010101。
权限值则有
ModuleValue
与
ActionCode
组合而成，采用下划线来连接。
实例：ModuleValue=Sys_User,ActionValue=AdD，PermitValue=
Sys_User_Add
权限组：
包括一组同一模块下的权限的组合，如管理用户包括基本的权限：添加、删除、修改、
查看等，将这些组合起来构成一个用户组——“用户管理”权限组。其它类似。只是为了更方
便的查看系统权限与权限的分配。
实例：如管理用户的权限代码为
010101à查看用户，010102à添加用户,010103à删除
用户，010104à修改用户，010105à审核用户等，将这些基本权限组合起来一个集合而构成
了“用户管理”权限组。
角色、职½、项目：
也就是按特定的需要划分一种权限的集合。½用角色授权表、职½授权表、项目授权
表来实现。授权表中存放的是权限代码
PermitCode,而不是权限组的 GroupCode
代码。
用户授权：
由用户授权表来实现，用户授权表中的
RoleCode、PositionCode、ProjectCode
分别
是角色表中
RoleCode
组成的串、
职½ 表
PositionCode
组成的串、
ProjectCode
组成的串。
与角色授权表中的角色代码
RoleCode、职½授权表中 PositionCode、项目授权表中的
ProjectCode
不对应（不是主表与从表之间外键关系）。
从而½够实现了一个用户可以拥有多个角色、多个职½、多个项目的情况。
用户授权表中的
PermitCode
为直接授权的权限代码串，直接给用户分配权限。
京公网安备 11010802033920号
Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved
评论