人员、用户组、角色、权限之间的关系

摘自：http://wxg6203.iteye.com/blog/682830

关于crm权限管理和用户组的融合方案

由于工作的需要，需要对老系统进行改造，涉及到权限的问题，下面是小弟的一点总结和思考，如有不正确的地方，请予以指正，谢谢！！！！

当前的的crm系统中新融入了“用户组”的概念，融入“用户组”的目的是为了能通过用户组架起人员和权限之间的桥梁。实现人员和权限的间接的多对多的关系。

一、对老系统部分功能合并到新系统的疑问

疑问1：存在“部门表”和“部门字典信息”，同时新融入的“用户组”的概念，这3者肯定有重复。现在系统中用的比较多的是“负责人”选择“用户名”或“负责部门”。其中的部门就是“用户组么”？回归到起点：即“用户组”和”部门”是一个概念么？

疑问2：一个部门或用户组肯定存在“等级”的概念：“经理”和“普通员工”。所以我认为此处的“等级”就是角色的概念。“角色”可能是需要的。

疑问3：用户组表和权限表之间存在关系。那么systemlogin中存在的“User_Right”就不会再起作用了，存在就会矛盾了（暂时存在只是维持老系统不出错），是不是该删除User_Right？

总结：理不清他们的具体的关系，以及他们存在的重复性。

二、个人理解的人员、用户组、权限、角色、菜单之间的关系

说明：

1.教师A可能属于“语文组”，也可能属于“地理组”。

2.“语文组”肯定会有“语文组组长”和“普通教师”一职，这就是“角色”。其中“语文组组长”可能只有一个人，但是“语文组普通教师”可能有多人：如教师A、教师B。（细粒度控制）。

3.“语文组”有多种权限，“语文组组长”有权限看“教师A”的提交的工作报告，也有权限看“教师B”提交的工作报告，以及批阅报告。“语文组普通教师”只能查看自己的工作报告，和批改学生的作文等操作。（细粒度控制）

总结：权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。

三、设计的原则

粗粒度：表示类别级，即仅考虑对象的类别(thetypeofobject)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度：表示实例级，即需要考虑具体对象的实例(theinstanceofobject)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How的问题，其他的权限问题留给业务逻辑解决。

举例：

人员--------------（所属用户组---角色）--------------对应的权限：说明

人员1-----------（组1-------------组长）---------------权限：批阅该组普通组员的报告。

人员1-----------（组2-------------组员）---------------权限：写报告。查看自己的报告。

人员2-----------（组1-------------组员）---------------权限：写报告。查看自己的报告。

人员3-----------（组1-------------组员）---------------权限：写报告。查看自己的报告。

人员4-----------（组2-------------组长）---------------权限：批阅该组普通组员的报告。

建议表：

人员表、

用户组表、

角色表、

权限表、

人员--组-角色表、

组-角色-权限表。

呵呵，有什么地方考虑的不好，欢迎扔鸡蛋或是提出意见！！！！