只要在系统中存在多个用户，必然会涉及到用户权限的处理问题。这篇文章，作者总结了用户权限的相关问题，包括定义、搭建和自己的思考，供各位参考。
前几天与一位产品朋友闲聊的时候有聊到某项目的用户权限应该如何设计的话题，当时在我脑海中闪过了许多解决方案，但是我却不知道如何有逻辑性的进行表达，于是我意识到是该总结输出的时候了……
一、什么是用户权限
用户权限是所有应用系统最底层的逻辑，只要系统中存在多用户，那么就必然会涉及到用户权限的概念。用户权限是集模块权限、功能权限、数据权限为一体的统称。
下面以一个ERP系统的部分场景为例来解释说明什么是用户权限，例如在一个ERP应用系统中包含了销售、采购、财务等功能。
模块权限
模块权限也叫菜单权限或应用权限，即决定一个用户在应用系统中可以使用哪些模块菜单。
在示例中，公司的销售人员就只能查看与销售相关的业务模块，而不应该能看到财务相关的功能模块。因此我们可以通过配置模块权限来实现不同用户的模块隔离。
功能权限
功能权限也叫按钮权限，即决定一个用户在一个业务模块中可以使用哪些功能按钮。
在示例中，普通销售人员在销售订单管理模块中只能有新增订单、编辑订单、删除订单、申请优惠等功能，而销售总监除了有这些功能外，还会多一些审批优惠、查看销售报表等功能。因此我们可以通过配置功能权限来实现不同用户在同一个业务模块中的功能按钮不同。
数据权限
数据权限可以细拆为查看数据权限和管理数据权限。
查看数据权限，即决定一个用户在模块中可以查看哪些数据记录。在示例中，普通销售人员在销售订单管理模块中只能查看自己创建的销售订单，而销售总监则可以查看整个销售部门的销售订单记录。因此我们可以通过配置查看数据权限来实现不同用户在同一个业务模块中的数据隔离。
管理数据权限，即决定一个用户在可以查看的数据基础之上允许对哪些数据进行操作。在示例中，所有采购人员在采购订单管理模块中都可以查看所有的采购订单，但是采购人员A只能对自己创建的采购订单进行编辑、删除等操作，不能对其他采购人员的订单进行操作。因此我们可以通过配置管理数据权限来实现不同用户在同一个业务模块中查看同样数据的情况下，可操作的数据不同。
用户权限的核心就是在一个应用系统中控制哪些用户能查看哪些模块的哪些数据以及可以对哪些数据做哪些操作。
这句话看上去可能比较绕，但带入实际业务流程就会很好理解了。
二、为什么要设置用户权限
在实际业务场景中，每个用户都是有自己的部门和岗位，所以设置用户权限的第一个目的就是职责分明。不同部门不同岗位的用户在应用系统中都需要有各自对应匹配的功能流程，这不仅可以简化用户操作和提升用户体验，还避免因功能模块繁杂造成用户的困扰与混淆。
其次是为了数据安全保障。各类数据都有着不同的敏感性，例如公司的所有客户信息、供应商信息、财务信息等一旦被泄露均可能产生严重后果。通过设置用户权限就能将不同的数据信息分别授权给部分指定人员，这样就有效防止了数据被泄露的风险。
另外还可以用于做个性化体验等操作，例如在SaaS版系统中可以利用后台运营系统的用户权限给部分用户开放灰度测试功能或给指定用户开放指定功能，以便于满足不同用户的多样化业务需求。
三、如何搭建用户权限
搭建一个好的用户权限体系就像修房子搭建一个稳定的地基一样。因此在设计用户权限体系时需要尽可能设置的通用一些，这样才有利于后续的系统建设以及响应需求变更。
我把之前负责和参与过的所有产品和项目综合整理出了一个通用的用户权限配置模型，如下图所示。
模块权限常用的搭建规则为
✧通常情况下，一个功能页面就是一个菜单配置项，然后可以根据实际的业务场景来决定是否配置二级或三级菜单等。
查看数据权限常用的搭建规则有以下几点（可根据实际业务情况选择）
✧我创建的：仅能查看自己创建的数据。
✧我参与的：仅能查看与自己有关联的数据，如自己创建的、业务数据审批人或抄送人是自己的。
✧本级部门创建的：仅能查看自己所在部门本级所有人员创建的数据。
✧本级及上级部门创建的：仅能查看自己所在部门本级及上级所有人员创建的数据。
✧本级及下级部门创建的：仅能查看自己所在部门本级及下级所有人员创建的数据。
✧全部：可以查看该模块的所有数据。
管理数据权限常用的搭建规则有以下几点（可根据实际业务情况选择）
✧我创建的：仅可以操作自己创建的数据。
✧我可见的：仅可以操作与自己有关联的数据，如自己创建的、业务数据审批人或抄送人是自己的。
✧我可见的：所有能查看的数据都可以操作。
功能权限常用的搭建规则为
✧按照模块中的功能操作按钮列举，越详细越好。
有些多应用型的系统则可以在模块菜单的前面再套一层应用权限配置，如下图。
在实际项目开发过程中，用户权限也不一定全部都需要做成可配置项，可根据项目的实际情况将上述搭建规则的部分权限直接在代码里写死控制，只不过这么干的后果就是当后期有关于权限的需求变动时，需要由程序员修改代码并发版之后才能生效。
四、补充说明与总结
在实际业务中，用户角色与用户通常是多对多的情况，即一个角色下存在多个用户，而一个用户也可能拥有多个角色。所以为了方便在系统中管理，我们可以设置“角色组”的概念。即将多个用户角色打包为一个角色分组，并将这个分组赋予用户，这样一个用户就同时拥有了这个角色组下的多个角色的权限。但是当一个用户同时拥有多个角色权限时，又会出现另外一个问题是这位用户在系统中最终的权限是什么呢？这个问题通常的解决方案有2种，一种是多个角色的权限取并集；另一种是让用户手动选择自己的当前角色。具体采用哪种解决方案可根据实际业务场景来决定。
关于数据权限还有一个常见的问题是当一位用户从A部门转移到B部门之后，那这位用户之前在A部门产生的数据是保留在A部门还是跟随用户转移到B部门呢？这个问题需要在做权限设计时提前考虑到，但具体如何处理也是需要根据实际业务场景来决定。
用户权限是应用系统的基础，没有绝对完美的建设方案，每个应用系统都需要结合实际业务场景和实际项目情况来搭建出最合适的用户权限体系。
本文由 @易小勇 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。