通用数据权限设计——列权限（一数据权限设计界面设计） _经验分享

数据权限设计思路（摘抄）
数据权限决定用户能看到什么数据、多少数据量。
我们常接触到的数据访问权限都通过组织机构去划分，在实际应用中，也可能会根据业务增加其他维度的访问权限，如终端门店管理中单独设置门店访问权限，企业多品牌营销中设置品牌访问权限等。
1、以机构层级向下覆盖
根据组织机构树设定用户默认拥有所属组织及以下的数据访问权限。也是最基础的一种数据权限，对于简单的
2、与角色融合的数据访问权限
在设定角色时，同时设置该角色对应功能权限下的的数据访问权限层级：本人、本部门、本部门及以下、全公司。
用户可视菜单中的数据权限由拥有该菜单的角色数据权限而定，且当一个用户拥有多个角色时，角色菜单有重叠的，取两角色中最大数据权限，或数据权限并集。
3、设置部门访问权限
用户默认拥有所属组织及下级组织的访问权限，同时可以自由配置其他部门的访问权限，使得某些数据可以跨部门查看。
相比常规的基于企业组织架构，权限向下覆盖的方式，采用部门访问权限配置可以根据业务需求灵活地配置用户的访问数据范围，避免了父、子、兄弟甚至其他节点间的数据共享纠结，实现跨部门数据共享。
将数据访问权限分配在用户上，足够灵活但也牺牲了维护便捷性，在用户特殊访问权限不多的情况下可以选择该类方法进行设置。
4、实际应用中根据业务需要划定数据及功能权限范围
在实际应用中，仅通过部门设置数据访问权限不一定能满足业务数据的分界要求，在具体的功能里往往通过部门访问权限+其他条件组合的情况来限制用户数据权限范围。
如【部门访问权限+角色标签】，公司内部有领导类的角色，某种业务的原始单据信息需要给高层领导类角色的查看权限，但涉及到管理分权又不想赋予该类人员所有部门访问权限，此时要么单独开入口查询所有信息，领导类角色功能权限中都配置上该页面，也可以在该页面查询数据时，在部门访问权限之前再加一层角色标签的判断逻辑，若角色标签为领导的则不需要根据部门访问权限过滤。
总结及碎碎念
B端系统权限设计中，系统权限区分为功能权限和数据权限，分别对应系统中的功能模块和系统中的数据，功能权限大多基于RBAC模型，并可根据业务需要引入角色继承、用户组、角色标签等概念，数据权限主要基于用户机构、角色，或单独在页面中根据实际需要进行配置。但最终，所有的设置都是需要基于业务，先有业务、需求后有产品，只是权限配置这一功能模块偏向于公司层面要求，受公司业务形态影响较小，所以能抽象出一套较广泛适用的系统方法。
2、用户权限管理，数据库表设计网上资料说权限设计 = 功能权限 + 数据权限，我认为还是很有道理的。之前项目中只涉及到功能权限，没有数据权限，原因是最开始设计时，数据已经绑定在特定的用户下了，而且涉及到的表数量很少，不需要单独考虑数据权限的问题。
权限管理，最细致的权限管理有用户，用户组，角色，权限，功能。根据不同的需求适当选择，如用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。
本系统设计如下：
数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。
表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。
功能权限详细设计请参考，本项目也是受此启发：
http://blog.csdn.net/painsonline/article/details/7183613/
需求：给一个原来没有权限的数据配置系统加上登录，权限功能，不同角色查同一张表返回结果不同。
思路：所谓数据权限，关注点在于实体属性值、条件、允许值，用户登录后，查询该用户的查询条件，根据条件获取数据即可。详细表结构设计可以参考： https://zhuanlan.zhihu.com/p/31339794
具体介绍一下每个字段含义：
（1）主键 id；
（2）acl_id 映射权限点表主键，代表每行记录是针对哪个权限点的；
（3）status 代表当前这条配置是否有效，方便临时激活与禁用；
（4）param 代表需要校验的参数名，允许一个请求有多个参数参与数据校验；如果参数复杂，比如包含对象，定义的参数可能为a.b.c 这种多级的形式，建议不要太复杂
（5）operation 代表数据拦截的规则，使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等，可以根据自己需要增加或减少支持的拦截规则
（6）value1 和 value2 用来和param、operation组成一个关系表达式，比如：1<=a<2
next_param_op 字段根据需要使用，如果一个权限点支持多条数据规则时，连接两个规则之间的操作，|| 还是 &&
（7）seq 字段用于某个权限点包含多条数据权限规则时的顺序
假设有这么一条数据，那么他的含义是：id为1（acl_id）的权限点，配置了一条有效（status=1）的数据规则，规则是：传入参数id（param）的值要大于（operation）10（value1）
这种设计很细致了，当然我的项目没有那么复杂，所以最终没有采用这个。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。
本系统跟权限相关的表结构如下：
权限设计的总结用户：参与系统活动的主体，如人。
角色：特定权限的集合；
权限：角色可使用的功能，分角色的功能权限和角色的数据权限；
RBAC设计方案：基于角色的权限设计方案,更好的管理用户；
操作类型：对资源可能的访问方法，如增加、删除、修改等；
功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；
资源：系统中的资源，主要是各种业务对象，如销售单、付款单等；数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；
数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况
权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况；
所以基于数据的权限设计（数据权限则是控制你可以看到哪些数据，比如市场A部的人只能看到或者修改A部创建的数据，他看不到或者不能修改B部的数据。）
第一步梳理：梳理层级关系（我们可以找出每一个层级的BOSS）
超级管理员：
集团管理员
城市管理员（我们也可对这个城市组织节点授权）
学校管理员（我们也可对学校组织节点授权）
部门管理员（我们也对对这个部门组织节点授权）
第二步：每一层建立角色
每个后台用户可以自定义角色，给相应的用户授权，每个后台用户的权限是上一个后台用户权限的子集，后台用户创立角色的权限是子集的权限子集；这里也可以首先给城市，学校，部门这个组织节点分配权限，当每一层的管理员建立角色分配权限时只能是这个城市权限的子集；
第三步：给角色授权
这里我要将所有的权限进行打散：系统功能的筛选无非是从：系统名称-模块名称-功能项（这里的功能项已经拆解到按钮级别了）
第四步：给用户授权
角色创立了，我们就可以对用户进行授权，角色和用户的关系可以是一对一，也可以是一对多的关系；
总结：
以上就是本人对如何做权限设计的总结分析，仅供大家参考，希望在工作中能够帮助到大家，也希望大家一起多提意见，指出不足，感谢阅读！
系统权限设计思路方法总结几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误操作、数据泄漏等风险的发生。但是，很多产品经理会对权限功能有一点害怕的心理，一方面是由于能参考的实例较少，权限管理算是一个“系统级”的基础功能，一般系统中只有管理员可以操作，不像其他功能可以通过去其他系统中试用体验，另一方面，对于权限功能普通用户无法操作使用，所以存在感较低，做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。
一 RBAC模型
目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。
1.角色的作用
如果没有角色的概念，直接用户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂，操作成本也会很高，同时容错能力也会变得很差。
而引入“角色”概念后，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。
2.引入用户组
一些大型的平台上，如果用户数量较大，新增角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这就大大减少了角色分配的工作量。
同理如果权限较多时也会存在一样的问题，对角色进行权限设置时也需要大量的操作，此时可以考虑引入权限组的概念，将关联性较强的权限大包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。
下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。
3. 角色继承的RBAC模型
在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，且可额外赋予权限。
此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。
继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和操作自己下属子节点的权限。
4. 限制的RBAC模型
在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。
因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。
此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。
限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。
根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。
三、权限的拆分与设计
通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？
这些都需要分析清楚才能进一步设计出完善的权限系统。
首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。
整体关系如下图所示：
因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。
保证初期设计支持后，配置权限时，还需要注意以下几点：
（1）确定是否支持前端配置
如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。
如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面” 。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。
（2）以基本单元拆分，以业务逻辑配置
一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。
但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有操作权限，则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。
（3）页面权限优先于操作和数据权限
必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限。
【通用数据权限设计——列权限（一数据权限设计界面设计）】 （4）查看权限优先于增删改权限
正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。
（5）角色与权限的多种关系
角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行操作，和以某种程度访问数据。
例如在“人员管理”中：
数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；
（6）角色与权限的设计表达
在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。
正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。
如下图所示：
四、需要注意的Tips
1. 隐形的admin
在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。
有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。
2. 初始权限的赋予
对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。
初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。
3. 人员管理中对自己的处理
在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。
4. 无页面权限的提示
虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug 。
总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。
节点包括：
用户；用户组；角色；角色组；权限（页面、操作、数据）；权限组（页面、操作、数据）；
如何设计ERP系统的数据权限？？按照岗位体系建立数据权限
应用：CRM
优点：1.设置简单，选择按照部门选择
缺点：1.需要维护一套岗位体系
2.不够灵活，不能看到跨部门数据（可以了解到其他部门的价值）也不能看到上级的数据（有个员工需要根据能力恒定自己的职业规划，那么他会以上级为参考点，去观察上级的销售数据如何）（人事财务需要看到整个部门的数据，他们也不是领导，他们是专员，而且那些人也不是他们的下属，无论如何都看不到数据）
针对角色设置数据权限（实习公司也是这样处理：班主任，助教，管理员）
优点：不受岗位框架影响，可以灵活设置，如果短期内没有负责到这部分数据，我就取消对应角色权限即可，但不用删除掉这个角色以及权限；再比如可以设置一个角色“宇宙总局xx指挥中心xx副局”，但实际上不存在这个岗位。
再比如，角色可以多层叠加，比如华南地区xxx就可以看到华南地区的数据；华东地区xxx就可以看到华东地区的数据；总局可以看到xx所有数据，但是我们不能让这个人看到所有数据，只需要让他负责华南与华东即可，则给他两个角色就好
怎么设置角色权限呢？
采用数据规则：规则编辑器
如：客户所在地区等于 AS地区且客户状态等于带续签，输出结果：交集
客户所在地区等于 B地区且客户状态等于入住或客户所在地区等于 K地区且客户状态等于签约，输出结果：并集
优点：1. 避免与岗位直接绑定，岗位变动则权限变动；
2.避免与岗位直接绑定，僵化管理，没有角色灵活
3. 可以适合多种特殊化场景（临时需求居多），用完就释放权限关系，避免数据泄露
缺点：1.需要维护角色与权限关系
2.数据规则较为复杂，需要进一步管理
3.如果是多层计算，同样数据规则也很复杂
专化岗位：提供岗位方案如：销售（A,B,C都是销售，但A负责a课程的物料，B负责b课程的人群转化以及转介绍，C负责d项目的引入）
不专化岗位：提供角色方案如：销售人事（一个月前负责xx项目的招聘工作，一个月后负责xx项目的培训工作）
总结：
数据范围划分清晰，准确
尽量减少维护成本（弄完一套规则体系后尽量不动维持原态）
设置灵活（可塑，可拆，可整合）
名词解释：
直接下属：辖域下面一层
所有下属：所有辖域，包括往下一层往下二层往下三层，，，
虚拟上级：一个节点
特殊情况处理：
人员变动：判断人员是否专化？ if 是，then 岗位；if 不是，then 角色方案。
部门变动（几乎很少）：
并入新部门：维持与新部门同个权限位置。
拆分：经讨论分析，评判每个用户的角色等级。
移出：撤销原有权限，载入并维持新权限。
通用数据权限设计——列权限（一）笔者认为WEB系统权限应归纳为功能权限，数据权限（行、列）
二者共同构建出应用系统的权限模型，接下来本文详细描述下列权限的设计理念。
column_permission：
column_handler ：
本文着重描写列权限设计的思想，具体祥设参考
通用数据权限设计——列权限（二）
关于数据权限设计和数据权限设计界面设计的内容就分享到这儿！更多实用知识经验，尽在 www.hubeilong.com

通用数据权限设计——列权限（一 数据权限设计界面设计）

通用数据权限设计——列权限（一数据权限设计界面设计）