关于crm权限管理和用户组的融合方案
由于工作的需要,需要对老系统进行改造,涉及到权限的问题,下面是小弟的一点总结和思考,如有不正确的地方,请予以指正,谢谢!!!!
当前的的crm系统中新融入了“用户组”的概念,融入“用户组”的目的是为了能通过用户组架起人员和权限之间的桥梁。实现人员和权限的间接的多对多的关系。
一、对老系统部分功能合并到新系统的疑问
疑问1:存在“部门表”和“部门字典信息”,同时新融入的“用户组”的概念,这3者肯定有重复。现在系统中用的比较多的是“负责人”选择“用户名”或“负责部门”。其中的部门就是“用户组么”?回归到起点:即“用户组”和”部门”是一个概念么?
疑问2:一个部门或用户组肯定存在“等级”的概念:“经理”和“普通员工”。所以我认为此处的“等级”就是角色的概念。“角色”可能是需要的。
疑问3:用户组表和权限表之间存在关系。那么systemlogin中存在的“User_Right”就不会再起作用了,存在就会矛盾了(暂时存在只是维持老系统不出错),是不是该删除User_Right?
总结:理不清他们的具体的关系,以及他们存在的重复性。
二、个人理解的人员、用户组、权限、角色、菜单之间的关系
说明:
1. 教师A可能属于“语文组”,也可能属于“地理组”。
2.“语文组”肯定会有“语文组组长”和“普通教师”一职,这就是“角色”。其中“语文组组长”可能只有一个人,但是“语文组普通教师”可能有多人:如教师A、教师B。(细粒度控制)。
3.“语文组”有多种权限,“语文组组长”有权限看“教师A”的提交的工作报告,也有权限看“教师B”提交的工作报告,以及批阅报告。“语文组普通教师”只能查看自己的工作报告,和批改学生的作文等操作。(细粒度控制)
总结:权限往往是一个极其复杂的问题,但也可简单表述为这样的逻辑表达式:判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
三、设计的原则
粗粒度:表示类别级,即仅考虑对象的类别(the type of object),不考虑对象的某个特定实例。比如,用户管理中,创建、删除,对所有的用户都一视同仁,并不区分操作的具体对象实例。 细粒度:表示实例级,即需要考虑具体对象的实例(the instance of object),当然,细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如,合同管理中,列表、删除,需要区分该合同实例是否为当前用户所创建。
设计原则归结为:“系统只提供粗粒度的权限,细粒度的权限被认为是业务逻辑的职责”。
需要再次强调的是,这里表述的权限系统仅是一个“不完全”的权限系统,即,它不提供所有关于权限的问题的解决方法。它提供一个基础,并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上,根据“业务逻辑”的独特权限需求,编码实现剩余部分(或者说细粒度的)部分,才算完整。回到权限的问题公式,通用的设计仅解决了Who+What+How 的问题,其他的权限问题留给业务逻辑解决。
举例:
人员--------------(所属用户组---角色)--------------对应的权限:说明
人员1-----------(组1-------------组长)---------------权限:批阅该组普通组员的报告。
人员1-----------(组2-------------组员)---------------权限:写报告。查看自己的报告。
人员2-----------(组1-------------组员)---------------权限:写报告。查看自己的报告。
人员3-----------(组1-------------组员)---------------权限:写报告。查看自己的报告。
人员4-----------(组2-------------组长)---------------权限:批阅该组普通组员的报告。
建议表:
人员表、
用户组表、
角色表、
权限表、
人员--组-角色表、
组-角色-权限表。
呵呵,有什么地方考虑的不好,欢迎扔鸡蛋!!!,或是提出意见!!!!
- 大小: 20.1 KB
分享到:
相关推荐
这个"java用户角色权限" demo旨在提供一个基础框架,来理解用户、角色和权限之间的交互关系。 首先,让我们详细探讨一下这三个核心概念: 1. **用户(User)**:在系统中,用户是实际的使用者,可能是管理员、普通...
### 角色权限用户之间的关系及设计原则 在软件系统特别是企业级应用中,权限管理是非常重要的一个环节。良好的权限管理不仅可以确保数据的安全性,还能提高系统的可用性和易用性。本文将深入探讨角色、权限与用户...
总结来说,C# WinForm中的权限控制通过角色和用户之间的关联,实现了细粒度的访问控制。通过合理的角色分配和权限设置,可以有效保护系统资源,防止未授权访问。在实际项目中,应根据具体需求设计和实现权限控制,...
### Java用户角色权限设计详解 在企业级应用中,用户角色权限设计是至关重要的环节,尤其是在B/S架构的系统中,因为用户权限检测不能仅依赖于客户端,必须有一套完整且严密的权限检测机制,以确保只有授权用户才能...
角色权限控制是IT系统安全管理中的核心机制,它用于管理和限制用户对系统资源的访问和操作。在"角色权限控制PPT"中,我们看到的是一个关于如何实施这种控制的案例,特别是针对中国CDCC(中国疾病预防控制中心)结核...
- **用户和用户组**:每个用户都属于一个或多个用户组,文件的权限也可以针对用户组设置。`chgrp`命令可以更改文件所属组,`chown`命令可以更改文件所有者。 - **访问控制列表(ACL)**:除了基础的用户/组权限,...
3. 数据库:存储用户、角色和权限的相关信息,包括用户-角色关系、角色-权限关系等。 4. RBAC引擎:负责权限的验证,判断用户是否具备执行操作所需的权限。 通过RBAC模型,企业可以更好地控制谁可以访问哪些资源,...
角色权限管理是一种有效的方式,它将用户的权限分配给不同的角色,每个角色拥有特定的一组操作权限。这种模式简化了权限分配的过程,同时也方便了系统的维护和扩展。下面我们将深入探讨角色权限管理的简单实现。 ...
在计算机系统中,角色是一组预定义的权限集合,它可以代表一个特定的用户群体,如管理员、普通用户或者销售人员。而权限则定义了用户可以执行的操作,例如读取、写入、删除文件,或者在系统中执行某些特定的功能。 ...
标题中的“基于角色权限管理PDM图”指的是在软件开发中使用的一种设计模式,即“基于角色的权限控制”(Role-Based Access Control, RBAC)。PDM是“产品数据管理”(Product Data Management)的缩写,通常用于管理...
- 角色分配:系统应提供角色分配功能,允许管理员将特定角色分配给特定用户或用户组,以便根据其职责和需求控制他们的访问权限。 2. **权限管理**: - 权限:权限定义了用户可以执行的操作,如查看、编辑、删除...
首先,用户组是权限管理的核心元素,它允许我们将多个用户归类并赋予相同的权限集。通过创建用户组,管理员可以一次性设定一组用户的访问级别,而无需逐个用户操作,大大提高了管理效率。例如,在`工程1.exe`和`工程...
本手册将指导您 adım adım 地理解和掌握 SAP 角色权限的设置。 一、角色设置的基本概念 在 SAP 系统中,角色是指一组权限的集合,这些权限确定了用户在系统中的操作权限。角色可以分为两种:标准角色和自定义...
在实际应用中,角色可以被定义为一组具有相同权限的用户集合。例如,"管理员"角色可能拥有系统的所有操作权限,"普通员工"角色可能只能查看和编辑自己的数据。通过这种方式,当需要修改某类用户的权限时,只需要调整...
在IT行业中,用户权限管理是系统安全的重要组成部分。本文将详细阐述如何进行用户组权限设置,...通过理解用户组、权限设置的基本概念,以及如何利用数据库和编程语言实现这些功能,我们可以构建出强大的权限管理系统。
企业级工程项目管理系统模型之系统基础:组织岗位用户角色权限V1.2 该系统模型的核心是组织岗位用户角色权限的设计和实现。组织是业务管理的基础,岗位是组织或部门中职责与权限的代表。用户是管理软件系统中使用者...
在这个上下文中,"用户角色权限.pdm"可能是一个描绘了用户角色、权限以及它们与系统资源之间关系的数据模型。 用户角色是用户身份的一种抽象,它将一组特定的权限捆绑在一起,便于管理和分配。例如,一个"管理员...
角色是用户组的一种抽象,用于分配特定的权限。权限则定义了用户可以执行的操作。 1. **角色管理**:在C#中,我们可以使用`RoleProvider`接口来实现自定义的角色提供程序,存储和检索角色信息。通常,这会涉及到...
对于数据存储的访问,必须同时拥有数据中心的“只读”权限和数据存储的特定角色权限。 需要注意的是,权限分配是递归的,意味着如果未取消“传播到子对象”的选项,权限会继承到子对象。因此,精细的权限控制要求对...