今天在公司差点出了大问题，也就是一个同事有超管权限，一不小心误操作修改了销售的部门，导致销售人员的页面全部消失，有几分钟销售人员无法工作，还好是中午吃饭的时间，没有多少销售同事在使用系统。没有造成重大事故。不过在短暂的十几分钟找到问题原因，将问题修复。因为这个问题，引起了我的思考。造成这个事故的原因，其实就是权限管理出了问题。说到底，权限系统就是操作权限+查询权限+数据权限。
查询权限
查询权限就是用户针对系统中具有的页面有访问的权限。例如：整个CRM系统有100个页面，A员工有权限查看其中的20个页面。
操作权限
操作权限说白了就是指用户对系统中某些页面的功能有操作的权限。例如：A员工可以查看其中的20个页面，其中有个订单查询页面，但是A用户不是相关的运营人员，更没有管理员权限，所以A用户只能查看订单信息，而不能对订单信息进行增加、删除、编辑等操作权限。
数据权限
数据权限指的是用户能够查看或者下载某些数据范围的权限。例如：订单中心包含订单号、订单归属人、时间、状态、价格，销售提成等。不同的角色在同一个页面看到的信息是不同的。财务可以查看到提成，因为财务需要给销售人员结算薪资。但是普通的技术人员或者其他的人员只能看到订单的基本信息等。
权限模型
权限模型释义
1、上图中1和N代表的是数量关系，1是代表只能有一个，N是代表可以无限个。例如：一个组织架构下有多个用户，但是一个用户只能拥有一个组织架构，所以组织 ： 用户 = 1：N，也就是我们常说的一对多的关系。其他以此类推。
2、根据RBAC权限模型设计，为了更加方便权限的管理，引入了用户组、角色甚至是部门的概念，一个用户可以是单独某一类角色，也可以加入一个群组。如果一个用户既有角色又有群组，两个同时存在时，那么该用户的权限就是一个角色+群组的并集权限。如图所示：
3、权限集合包含了页面查询权限、功能权限、数据权限。其中数据权限和功能权限是依赖于页面的查询权限的。也就是说，想要拥有某个页面的数据权限或者查询权限，必须配置某个页面的查询权限，否者的话无法配置页面的数据权限和功能权限。
权限的流程设计
1、用户登录系统以后，首先判断该用户组织架构关系，获取该用户的组织架构。
2、判断该用户层级，也就是判断该用户在这个组织架构下面属于哪个用户组、角色权限。
3、获取该用户的权限后，在该用户进入对应的页面时，就有对应的数据权限、功能权限、查询权限。
页面设计
组织架构管理
根据业务模式每个层级相当于一个新的组织，每个层级可以任意的建立下级组织。原则是没有层级上的限制。也就是总部、分部、分部下面设置各个部门、各个部门还有可能设置各个工作小组等。在总部的账号上，可以查看到每一个账号的归属和所有的交易数据、订单数据、业务数据等，而每个组织（分部、分部下的部门等）只能查看到自身的数据以及下级分支的数据，不能跨组织架构进行查询和数据相关的操作。
功能菜单配置
功能菜单配置包括页面权限配置、页面中按钮权限配置。由于一级菜单不能随意进行添加，所以这个配置只有二级菜单的配置权限。而一级菜单只能有通过开发执行sql才能添加进去。
部门配置
根据RBAC原则，每个用户可直接关联角色或权限组。根据实际业务场景，将权限组与角色进行关联。用户直接与权限组关联，而权限组与角色是具有绑定关系。并且只有特殊的角色查询时才有限制，例如某个产品线运营，只能查询下载自身所在产品线的用户交易数据。
权限配置
图片来源于网络
员工配置
（1）员工配置需要关联到相关的部门才能获取对应的权限，一个员工可以拥有多个部门，相当于是可以拥有多个部门的权限集合。
（2）每个员工都配置对应的员工级别，分为普通员工和部门经理。这样分配的原因是，类似于销售类这种角色，普通销售只能查看自己的订单和客户。但是销售总监级别是查看下属销售的权限的。所以如果在同一个部门，属于部门经理的。在查看数据时，可以查看该部门员工的所有的数据。
图片来源于网络
数据权限配置
（1）上述所有的配置都是页面和按钮的配置，针对数据字段的查看和下载需要单独的页面进行配置，在点击页面时自动获取对应的查询权限的模板，点击下载时读取对应的模板进行下载。
（2）默认权限可配置在某个部门下，这样可避免无特殊要求的部门不需要重复的进行配置，统一读取默认配置即可。
图片来源于网络
总结
以上讲述了系统整体的权限设计的思路，对整体的流程、权限模型、页面设计做了详细的梳理，总结归纳如下：
梳理业务中组织架构与相关人员的角色关系，输出相应的组织架构图。
根据组织架构图设计相关的权限模型，模型中将涉及的参数的数量关系梳理清楚，并且在后续的页面设计中使用。
了解RBAC权限设计体系，理解用户、用户组、角色与权限的关系。根据业务的实际场景，将RBAC权限体系适用于自身业务。
最后感谢大家阅读完本文，如有写的不对的地方，请批评指正错误，欢迎大家一起来探讨。
网友评论