权限设计（功能权限与数据权限）

转自：https://zhuanlan.zhihu.com/p/396125748

权限设计的最终目标就是定义每个用户可以在系统中做哪些事情。

 

当我们谈到权限的时候，一般可以分为 功能权限、数据权限和字段权限；

功能权限：用户具有哪些权利，比如特定单据的增、删、改、查、审批、反审批等等；一般按照一个人在组织内的工作内容来划分；比如一个单据往往有录入人和审批人，录入人具有增、删、该、查的权限；而审批人具有审批、反审批和查询的权限。有时，功能权限被细分为页面权限和操作权限。

数据权限：用户可以看到哪些范围的主数据，比如按照部门或业务条线来划分。用户张三看到A团队的数据，用户李四只能看到B团队的数据。

字段权限：在特定的单据中，可以看到哪些字段；比如针对入库单，财务人员能看到采购成本，而库管员看不到等等。字段权限和数据权限的区别在于，数据权限规定了哪些行的数据看不到，而字段权限规定了哪些列的数据看不到；这种权限设计现在见的比较少了，因为如果两个用户看到的列都不一样，通过设计不同的表单也能实现，此时字段权限就转换为功能权限了。

 如上图所示，数据权限决定用户看到的是团队A还是团队B的数据，字段权限决定能否看到金额这一列的数据。

对功能权限和数据权限的抽象

这个就是角色的引入，网上有很多这方面的文档介绍可以参考，我这里挑重点简单说一下；

在一般的组织中，用户的权限是由岗位决定的，由于用户可能面临转岗、离职等工作；所以岗位和权限的关系比用户和岗位的关系要稳定的多。

所以为了简化用户权限的分配操作，降低操作风险；同时，也便于把权限管理移交给统一的用户管理部门，一般会引入角色的概念，作为功能权限和数据权限的抽象；

 注意：权限、角色和用户是多对多的关系；

数据权限的进一步抽象

考虑一种场景，一个集团有50个分支机构，每个分支机构下平均有3个部门，各个部门的组织架构是大体类似，在系统中都分为单据的录入者、复核者、审批者和查询者；这种情况下，如果按照角色来设置，需要设置50*3*4共600个角色；而且一旦面临的部门和团队的增加和撤销，也面临角色的大量设置和调整。

由于这个组织结构比较均匀，所以用户权限其实等同于功能权限和数据权限的交叉组合，功能权限表示横向的录入、复核、审批和查询权限；数据权限表示具体某个分支机构下的部门。

数据权限的抽象，有些系统称之为“岗位”，有些称之为“组织”，鉴于“岗位”和角色的含义有些冲突，此处暂且称之为“数据组织”吧。

刚才的案例中，如果使用角色+数据组织的组合，只需要预设置50*3=150个数据组织和4个角色。而且方便于将来的组织拓展，比如某个分支机构下要新增一个团队，按照原来的方案，需要新增4个角色，现在只需要在基础资料里加1个数据组织就可以了。

 

数据组织的层级管理

多层级组织时，上级组织往往具有下级组织的所有数据权限；所以通过设置组织的层级关系能进一步优化配置方案。比如上图中上海分支机构下的团队a和团队b都可以合并为一个数据组织，华东片区的数据组织可以在这个基础上继续向上合并。

一人多岗和交叉型的组织结构

数据组织和角色能发挥作用的前提是组织呈现出纵向部门团队和横向岗位的完美组合关系；但是实际上可能存在一人多岗的情况，则破坏了这种规则。比如用户张三是A团队的录入人和B团队的审批人；如果按照刚才的方案，角色设置为录入岗和审批岗，数据组织设置为A团队和B团队；那么实际的效果是用户张三同时具备A团队和B团队的录入+审批权限。

还有一些临时型组织，可能会从原来的组织中跨部门、跨团队抽调人员形成临时性的新组织，而这些用户原来的组织岗位仍然保留；也会出现这种问题；所以要采用新的规则进行处理。

处理方案有2种；

1、新增用户名，相当于一个用户有多个用户名，每个用户名赋予的权限的不同。优点是逻辑简单，设置便捷。但是缺点也很明细，随着信息化系统的建设越来越多，用户需要管理的用户名已经越来越多，密码越来越复杂，多用户名容易造成混乱；而且有的公司为了整合用户管理和权限管理，使用公司门户网站跳转到各个应用系统的方式，不太支持多用户名；

2、建立数据权限的优先级。上述这个案例，如果将数据权限绑定在角色上，则可以通过让用户切换角色来实现权限的控制；

所以解决方案是：

角色和用户名都可以绑定数据组织；但是角色的优先级高于用户。只有到角色没有绑定数据组织时，系统获取用户名所对应的数据组织。

 

如上图所示，张三同时具有录入角色和审批角色，用户名本身绑定的数据组织是北京的团队；当张三切换到录入角色时，由于录入角色没有绑定数据组织，所以使用其自身的数据组织，那么张三只能新增北京分支结构团队A的单据；如果切换到审批角色时，由于审批角色绑定了上海的数据权限，所以张三只能查询并审批上海分支机构b提交的单据。

有的系统数据权限设计的更为复杂，可以分配给角色、数据组织和用户名本身，在此基础上建立优先级关系，从事实现更为复杂和灵活的权限配置。

审批的处理

审批本身无需特殊说明，这里单拉出来是因为自己负责过一个项目，本来权限的架构是按照上面的思路进行的，但是由于涉及的数据计算量很大，开发商给的方案是按照批次进行提交和审批，我想了一下，觉得没有什么问题就同意了。然而在实操中产生了一定的问题。

多层组织结构下，上级组织会审批来自于下层组织的数据；审批可以按照批次或按照最明细的数据；按照最明细的数据进行审批，其逻辑和上面描述的一样，一般没有什么问题。

但是按照批次的话，需要保证提交者的批次数据，必须全部被审批人看到，而不能部分被看到；否则这批数据同时存在已审批和未审批两种状态。换句话说，审批人的数据权限必须完全包含被审批人的这一批次数据权限；在权限设计时需要额外加一些校验。当时项目的问题是，由于一个批次数据量太大，复核人需要分批进行复核，后来发展为2个复核人对同一个人的数据，根据不同的业务场景进行分工复核，和上面的原则产生了冲突。

有人问了字段权限转换为功能权限是什么意思。假设有一张表单叫做学生基础资料信息表，有 姓名、年龄、学院、班级和身份证号码等信息，由专人进行维护。这时假设另外有一个用户张三，做学生成绩统计的，要根据学生清单，录入每个学生的成绩，那么就需要把学生基础资料表的访问权限开放给他。但是身份证号码是敏感信息，作为学生成绩统计来说，也不需要这个字段。那系统要怎么设计，才能让用户张三既访问到学生清单，又看不到身份证号码？字段权限和功能权限都是为了解决这个问题。 功能权限实现方法很多，比如可以新增一个表单，叫做学生清单表，有姓名、年龄、学院和班级，但是没有身份证号码；当学生基础资料信息表保存时，就将表里的信息同步到学生清单表里，唯独不同步身份证号码。 在权限管理时，只给张三学生清单表的权限，不给他学生基础资料表的权限。就实现了这个功能。

之所以现在功能权限的做法比较多，个人认为原因之一就是开发工具的进步，新表单的开发和权限的配置已经非常便捷了，与其增加字段权限这样一个控制维度，不如多个表单简单粗暴的解决问题。