一个用户权限管理模块的设计思路

：一个用户权限管理模块的设计思路

一、

1. 权限资源（功能资源）

系统的所有权限信息。权限具有上下级关系，是一个树状的结构。如下：

<!--[if !supportLists]-->u  <!--[endif]-->系统管理

<!--[if !supportLists]-->l  <!--[endif]-->单位管理

<!--[if !supportLists]-->u  <!--[endif]-->查看单位

<!--[if !supportLists]-->u  <!--[endif]-->添加单位

<!--[if !supportLists]-->u  <!--[endif]-->修改单位

<!--[if !supportLists]-->u  <!--[endif]-->删除单位

 
<!--[if !supportLists]-->l  <!--[endif]-->部门管理

<!--[if !supportLists]-->u  <!--[endif]-->查看部门

<!--[if !supportLists]-->u  <!--[endif]-->添加部门

<!--[if !supportLists]-->u  <!--[endif]-->修改单位

<!--[if !supportLists]-->u  <!--[endif]-->删除单位



对于每个权限，又存在两种情况：1可访问；2可授权，部分表中采用拥有类型做判断(0可访问，1即可访问也可授权)



2. 用户

系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。



3. 角色

为了对拥有相似权限的用户进行分类管理，因此定义角色，例如：超级管理员，一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系，形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。



4. 组

为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际应用中，我们知道，组也可以具有自己的角色信息、权限信息。

就好比是javaeye中的圈子，一个圈子可以拥有多个会员，同时一个会员也可以加入多个圈子，对于不同的圈子又有不同的权限信息。(组的解释：例如一个公司中，不同的部门即可划分不同的组来进行权限的分配)



针对以上描述，结构关系如下：





整个模块分为组权限管理、角色权限管理、用户权限管理。

其中组权限管理：组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理：角色权限 = 角色自身权限。

用户权限管理：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。



注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。

二、
做过些系统，用过人员←→功能权限、人员←→部门←→功能权限、人员←→岗位/职务←→功能权限、人员←→分级机构←→功能权限等各种权限管理方式，最后还是感觉人员←→角色←→功能权限这种方法最简单实用，好处理，也好跟客户讲解。
简单来说就是先给角色分配功能操作权限，再为人员分配角色，一人员可以承担单一角色或者多角色，当其岗位或者工作任务变化时直接调整角色，当角色权限不能满足工作需要时再增加角色调整或者角色权限，什么问题都解决了。这种方法最适合国内客户。
角色是虚拟的事物，客户那开始时有不理解的，就跟客户说，比如角色其实跟岗位差不多，但实情是：
一、岗位职责在软件系统中仍可能存在不明确，从人管到机管的过渡中这样的事时常有。
二、兼管，本来不在岗位职责的工作需要兼管，或者临时代管，用角色来替代很合适。
三、岗位在单位中特别是大中型企业中是固定的，专岗专责，这时用虚拟的角色来完成岗位固定、分工不同更恰当不过。