??xml version="1.0" encoding="utf-8" standalone="yes"?> l 可以?#8220;l?#8221;q行权限分配。对于一个大企业的业务系l来_如果要求理员ؓ其下员工逐一分配pȝ操作权限的话Q是件耗时且不够方便的事情。所以,pȝ中就提出了对“l?#8221;q行操作的概念,权限一致的人员~入同一l,然后对该l进行权限分配?
l 权限理pȝ应该是可扩展的。它应该可以加入CQ何带有权限管理功能的pȝ中。就像是lg一L可以被不断的重用Q而不是每开发一套管理系l,p针对权限理部分q行重新开发?
l 满业务pȝ中的功能权限。传l业务系l中Q存在着两种权限理Q其一是功能权限的理Q而另外一U则是资源权限的理Q在不同pȝ之间Q功能权限是可以重用的,而资源权限则不能?/p>
针对OApȝ的特点,权限说明Q?
权限
在系l中Q权限通过模块+动作来生,模块是整个pȝ中的一个子模块Q可能对应一个菜单,动作也就是整个模块中Q在B/Spȝ中也是一个页面的所有操作,比如“览、添加、修攏V删?#8221;{)。将模块与之l合可以产生此模块下的所有权限?
权限l?/strong>
Z更方便的权限的管理,另将一个模块下的所有权限组合一Pl成一?#8220;权限l?/strong>”Q也是一个模块管理权限,包括所有基本权限操作。比如一个权限组Q用L理)Q包括用L览、添加、删除、修攏V审核等操作权限Q一个权限组也是一个权限?
角色
权限的集合,角色与角色之间属于^U关p,可以基本权限或权限l添加到一个角色中Q用于方便权限的分配?
用户l?/strong>
某一cd的h、具有相同特征hl合一L集合体。通过对组授予权限Q角ԌQ快速一cMhh相同的权限,来简化对用户授予权限的繁琐性、耗时性。用L的划分,可以?strong>职位、项?/strong>或其它来实现。用户可以属于某一个组或多个组?
通过l某个h赋予权限Q有4U方?参考飞思办公系l?
A. 通过职位
a) 在职位中Q职位成员的权限l承当前所在职位的权限Q对于下U职位拥有的权限不可l承?
b) 实例?/strong>Q如前台q个职位Q对于考勤查询有权限,则可以通过对前台这个职位设|考勤查询的浏览权Q他们有用这个对象的权限Q然后再讄个,考勤查询权(当然也可以不讄Q默认能q此模块的就能查询)Q则所有前Ch员都拥有考勤查询的权利?
B. 通过目
a) 在项目中Q项目成员的权限来自于所在项目的权限Q他们同样不能承下U项目的权限Q而对于项目组长,他对目有全权,对下U项目也一栗?
b) 实例?/strong>Q在目中,目成员可以寚w目中上传文档Q查看本目的文?可以通过寚w目设|一个对于本目的浏览权来实现进口,q样每个成员能访问这个项目了Q再加上目文档的上传权和查看文档权卛_?
c) 对于l长Q因为可以赋予组长一个组长权Q组长权是个Ҏ的权限,它包含其他各U权限的一个权限包Q,所有组长对于本目有全权,则项目组长可以对于项目文档查看,审批Q删除,恢复{,q些权限对于本项目的下目依然有效?
C. 通过角色
a) 角色中的成员l承角色的权限,角色与角色没有上下关系Q他们是q的。通过角色赋予权限Q是指没办法按职位或目的分cL赋予权限的另一U方式,如:pȝ理员,资料备䆾?#8230;
b) 实例?/strong>Q对于本pȝ中,全体人员应该默认都有的模块,如我的邮Ӟ我的文档Q我的日志,我的考勤……Q这些模块系l成员都应该有的Q我们徏立一个角色ؓpȝ默认角色Q把所有默认访问的模块的浏览权加入到里面去Q则pȝ成员都能讉Kq些模块?
D. 直接指定
a) 直接指定是通过Ҏ个h具体指定一Ҏ限,使其有用这个权限的能力。直接指定是角色指定的一个简化版Qؓ了是在徏立像某个目的组长这U角色时Q省略创色这一个步骤,使角色不至于q多?
b) 实例?/strong>Q指定某个项目的l长Q把l长权指定给某个人?
针对职位、项目组Q?/strong>
如果用添加新员工Q员工调换职位、项目组Q满了员工会自动承所在职位、项目组的权限,不需要重新分配权限的功能?
用户理
用户可以属于某一个或多个用户l,可以通过对用L授权Q来对组中的所有用戯行权限的授予。一个用户可以属于多个项目组Q或担Q多个职位?
授权理
一个基本权限或角色授予用户或用LQ用户或用L拥有授予权限的字W串Q如果角艌Ӏ职位、项目中存在相同的基本权限,则取其中的一个;如脱角艌Ӏ职位、项目组Q只是取消用h用户l的中此角色、职位、项目组所授予的权限。用h拥有的权限是所有途径授予权限的集合。管理员用户可以查看每个用户的最l权限列表?
权限理
基本操作权限与权限组Q基本操作权限的集合Q的理?br />
OA权限理设计的实?nbsp;
物理数据模型囑֦下:
Ҏ以上设计思想,权限理d需要以下基本表Q?
tb_UserQ用户信息基本表Q?
tb_DepartmentQ部门表Q?
tb_CompanyQ公司表Q?
tb_ModuleQ系l模块表Q?
tb_ActionQ系l中所有操作的动作表;
tb_PermitQ由tb_Module与tb_Action两表l合产生的系l基本权限表Q?
tb_Permit_GroupQ权限组表,一模块的中的所有权限划分一个权限组中,可以通过权限l授予用h限;
tb_RoleQ角色表Q基本权限的集合。无上与下U之分;
tb_PositionQ职位表Q有上与下U之分;
tb_ProjectQ项目组表,
tb_Role_PermitQ角色授权表Q?
tb_Postion_PermitQ职位授权表Q?
tb_Project_PermitQ项目授权表Q?
tb_Project_UserQ项目成员表QIsLead字段代表此成员ؓ目l长Q?
tb_Postion_UserQ职位成员表Q?
tb_User_PermitQ用h权表Q用户ID与角艌Ӏ职位、项目及直接授予的权限串表;
权限的生:
由tb_Module中的ModuleCode与tb_Action中的ActionCodel成
权限代码PermitCode=ModuleCode+ActionCode?
实例QModuleCode=0101QActionCode=01,则PermitCode=010101?
权限值则有ModuleValue与ActionCodel合而成Q采用下划线来连接?
实例QModuleValue=Sys_User,ActionValue=AdDQPermitValue= Sys_User_Add
权限l:
包括一l同一模块下的权限的组合,如管理用户包括基本的权限Q添加、删除、修攏V查看等Q将q些l合h构成一个用L—?#8220;用户理”权限l。其它类伹{只是ؓ了更方便的查看系l权限与权限的分配?
实例Q如理用户的权限代码ؓ010101à查看用户Q?10102àd用户,010103à删除用户Q?10104à修改用户Q?10105à审核用户{,这些基本权限组合v来一个集合而构成了“用户理”权限l?
角色、职位、项目:
也就是按特定的需要划分一U权限的集合。用角色授权表、职位授权表、项目授权表来实现。授权表中存攄是权限代码PermitCode,而不是权限组的GroupCode代码?
用户授权Q?
qh权表来实玎ͼ用户授权表中的RoleCode、PositionCode、ProjectCode分别是角色表中RoleCodel成的串、职位表PositionCodel成的串、ProjectCodel成的串。与角色授权表中的角色代码RoleCode、职位授权表中PositionCode、项目授权表中的ProjectCode不对应(不是主表与从表之间外键关p)?
从而能够实C一个用户可以拥有多个角艌Ӏ多个职位、多个项目的情况?
用户授权表中的PermitCode为直接授权的权限代码Ԍ直接l用户分配权限?
实例Q?
用户ID为UserId=1的用h限授权表的记录ؓQ?
RoleCode=001,003
PostionCode = 001,002
ProjectCode=001,005
PermitCode = 010101,020102
表明此用h有两个角Ԍ代码?01?03Qƈl承q两个角色的权限Q?
担Q两个职位Q代码ؓ001?02Qƈl承两个职位的权限;
属于两个目l中的成员,目代码?01?05Qƈl承两个目中的权限?br />
直接指定l用L权限?10101?10102q两个权限代码的权限
用户权限字符Ԍ
Ҏ用户授权表的角色代码、职位代码、项目代码得到权限字W串及表中直接分配的权限字符串组合成一个用L所有权限字W串集合?/p>
物理数据模型?nbsp;
1.{权限pȝ
q种权限pȝ在论坛中很常见,在这U系l中Q权限别如同官阶从低到高排列,每个用户拥有一个权限,其中讑֮了这个用L权限{Q在用户需要执行操作前先查看其权限{是否大于执行操作所需要的权限{Q是则进行操作?/p>
在等U权限系l中领域对象用户cUser的基本属性如下:
id // 用户ID
name // 用户?/strong>
领域对象权限cPrivilege的基本属性如?
id // 权限ID
userid // 持有此权限的用户id
level // 用户的权限等U?/strong>
level的设|示?br />
level 对应可执行的功能
0 讉K
1 可跟?br />
2 可创Z?br />
3 可删除主?br />
4 可创建频?br />
5 可删除频?br />
6 可查看用?br />
7 可分配用h?br />
8 可修改用户密?br />
9 可删除用?br />
...
使用?执行一个操作比如创Z贴时,先从Session中取出用?然后按其id查出其对应的权限{,拿它和执行创Z贴所需要的{(3)q行比较,高于则可q行创徏主脓操作,否则报告权限不够.
{权限pȝ单易?在如论坛{刚性控制系l中使用很好,但不适用于需要限制权限的范围的场合?/p>
2.范围限制权限pȝ
{权限pȝpȝ的缺Ҏ控制范围q广,比如一个论坛中有很多子论坛,一个子论坛的分版主同时也能对另一个同{分论坛的帖子q行控制,q在一定程度不合理Q有界的嫌?更好的做法是版L限控制在一版之?q时我们可以采用范围限制权限pȝ. q种权限pȝ在项目管理系l中很常?
在等U权限系l中领域对象用户cUser的基本属性如下:
id // 用户ID
name // 用户?/strong>
领域对象目cProject的基本属性如下:
id // 目ID
name // 目?/strong>
领域对象权限cPrivilege的基本属性如?
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的目
level // 用户的权限等U?br />
其中,通过引入了新属性projectid,我们Ҏ限的范围q行了有效限?目不同则权限等U再高也是无?q样pvC限制权限能力范围的作?
3.范围限制单项权限pȝ
在上面两个权限系l中,权限高的自然能执行权限要求低的操?q样做权力没有细?在有些场合ƈ不合?比如即是董事长不可直接操作Z部的招聘d,他只寚w员去留有?对于q样的场合我们需要用范围限制单Ҏ限系l?它的典型应用如工作流和OApȝ?/p>
在范围限制单Ҏ限系l中领域对象用户cUser的基本属性如下:
id // 用户ID
name // 用户?/strong>
领域对象目cProject的基本属性如下:
id // 目ID
name // 目?/strong>
领域对象权限cPrivilege的基本属性如?
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的目
abilityid // 权限控制能力id
领域对象权限控制能力cability的基本属性如?
id // 控制能力ID
item // 控制能力子项
item的设|示?br />
item 对应可执行的功能
0 ?br />
1 ?br />
2 ?br />
3 ?/p>
...
通过Ҏ限能力的l分,用户权限的控制粒度更l了,对功能和程p有更_的把?适用于复杂的场合.
以上三种权限pȝ没有优劣之分只有适用场合的区?前面的粗略但易于操作,后面的精但׃烦琐,在现实用中我们应该Ҏ场合选择合适的权限pȝ.