实例分析：后台权限设计

在上一篇文章中，小编为您详细介绍了关于《FF正在中东、欧洲和亚太地区多方推动债权和股权融资》相关知识。本篇中小编将再为您讲解标题实例分析：后台权限设计。

原标题：实例分析：后台权限设计

本文从权限设计的概念和基础角色关系出发，结合案例为我们介绍了权限设计模型、流程和页面配置，与大家分享。

一、基本概念

权限设计大概可以分为查询权限、操作权限、数据权限。

1. 查询权限

查询权限是指针对系统中具体的页面有访问的权限。例：整个系统中有三十个页面，A员工权限只能查看其中的十个页面。

2. 操作权限

操作权限是指系统中的功能按钮有具体的操作权限。例:A员工在查看到十个页面里，其中一个页面是商户查询页面，但是A不是运营人员，所以只能查询商户信息，而不能对商户进行新增、修改、删除等操作权限

3. 数据权限

数据权限是指能够查看或下载的数据范围的权限，例：订单页面中包含订单号、时间、状态成本、毛线、分润、销售提成等。不同角色在同一个页面看到的信息是不同的。财务部门可以查看到全字段的，因为需要进行核算。普通技术人员只能看到订单号、时间、状态等基础信息。

二、角色关系梳理

首先梳理一下新零售系统的层级关系，主要根据业务模式区分为自营商户和入驻商户（即商户A、B和C）。

1. 入驻商户组织架构

根据商户的实际的业务情况，了解到在设备铺设的城市会设置该城市分支机构，城市下区县会有对应的库存统一管理，可以统一的调配各自下属的区域的商品销量、库存情况进行统计分析。每个月区域会有对应的区域经理角色，单独的管理一个区域。每个区域下会有多台设备，每个设备会有对应的维护人员、商品补充人员，每个人员会同时的维护多台设备。所以商户的整体的组织架构的层级下： 商户的总部->城市管理->区县管理->区域管理->设备管理。

2. 自营商户组织架构

自营商户的组架构与入驻商户的差不多，只是自营商户的层级比较少，少了一个城市的区分，直接下放到地区，比较扁平一些。自营的组织架构如下：自营商户->自营地区->自营区域->自营设备。

3. 整理新零售组织架构图

三、权限模型设计 1. 权限模型梳理

根据新零售系统的组织架构，可以得出的结论是每一个层级会有对应的管理人员、运营人员、库存管理、财务等角色。所以在设计权限管理时，需要考虑每个层级之间属于单独的一个组织。高级别的组织可以查看到低级别组织的数据内容，但是低级别组织不允许跨级查看。同时低级别组织可以继承高级别组织的权限，即高级别组织可以自由分配低级别权限内容。

2. 权限模型

3. 权限模型具体内容解释

（1）上图中1和N代表的是数量关系，1是代表只能有一个，N是可以无限个。例如一个组织架构下有很多用户，但是一个用户只能拥有一个组织机构，所以组织:用户=1:N，其他也是以此类推即可。

（2）根据RABC权限模型设计，为了更加方便权限的添加与管理，引入了用户组、角色的概念，一个用户可以是单独某一类角色，也可以加入一个群组。如果两者共同存在时，那么此时该用户的权限则是一个角色+群组的并集。如下图所示，一个用户可以同时拥有用户组和角色。

（3）权限集合包含了页面查询权限、功能按钮、数据权限。其中数据权限、功能按钮是依托于页面查询权限，如果单独配置数据权限或功能按钮权限，不配置相应的页面查询权限，那么数据权限和功能按钮权限则无法展示，也就没有实际用。有些特殊情况可以利用这个方式也处理权限。例如当多个页面的都有相同功能，这些功能又是放置在同一个权限上，可以通过控制页面权限而达到控制这部分按钮的目的。

四、权限获取流程设计

（1）用户登录成功后，首先判断账号的组织归属，获取改账号的组织层级，因为在添加组织时管理员账号是必填选项，并且权限也是必填选项，所以不存在有账号会没有组织情况。（PS：公司运营人员也属于最高级别组织）

（2）获取用户层级后，判断该用户在这个层级归属的用户组、角色权限，如果没有对应的用户组与角色，那么就使用该层级的默认权限。默认权限可配置。

（3）获得用户的权限后，在进入对应的页面时获得对应的操作和数据权限。

五、页面配置设计 1. 组织管理

根据业务模式每个层级相当于是一个新的组织，所以便有组织管理存在。每个层级可以任意的建立下级组织，原则上是没有层级的上限限制。在总部账号上，可以查看到每一个账号的归属和所有的交易数据、商户信息等数据，而每个组织只能查看自身数据以及下级分支数据，并不能跨组织进行查询和操作数据。

2. 功能菜单配置

功能菜单配置包括页面权限配置、页面中按钮权限配置。由于一级菜单不能随意进行添加，所以这个配置只有二级菜单的配置权限。而一级菜单只能有通过开发执行sql才能添加进去。

3. 部门配置

（1）根据RABC原则，每个用户可直接关联角色或权限组。小编根据实际业务场景，将权限组与角色进行关联。用户直接与权限组关联，而权限组与角色是具有绑定关系。并且只有特殊的角色查询时才有限制，例如某个产品线运营，只能查询下载自身所在产品线的商户交易数据（PS：产品线是通过商户属性划分，看各公司规定）。

（2）权限配置

4. 员工配置

（1）员工配置需要关联到相关的部门才能获取对应的权限，一个员工可以拥有多个部门，相当于是可以拥有多个部门的权限集合。

（2）每个员工都配置对应的员工级别，分为普通员工和部门经理。这样分配的原因是，类似于销售类这种角色，普通销售只能查看自己的订单和商户。但是销售总监级别是查看下属销售的权限的。所以如果在同一个部门，属于部门经理的。在查看数据时，可以查看该部门员工的所有的数据。

5. 数据权限配置

（1）上述所有的配置都是页面和按钮的配置，针对数据字段的查看和下载需要单独的页面进行配置，在点击页面时自动获取对应的查询权限的模板，点击下载时读取对应的模板进行下载。

（2）默认权限可配置在某个部门下，这样可避免无特殊要求的部门不需要重复的进行配置，统一读取默认配置即可。

六、总结

以上讲述了系统整体的权限设计的思路，对整体的流程、权限模型、页面设计做了详细的梳理，总结归纳如下：

1. 梳理业务中组织架构与相关人员的角色关系，输出相应的组织架构图。
2. 根据组织架构图设计相关的权限模型，模型中将涉及的参数的数量关系梳理清楚，并且在后续的页面设计中使用。
3. 了解RABC权限设计体系，理解用户、用户组、角色与权限的关系。根据业务的实际场景，将RABC权限体系适用于自身业务。

最后感谢大家阅读完本文，如有写的不对的地方，请批评指正错误，欢迎大家一起来探讨。

本文由 @TOM 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。游戏网

编后语：关于《实例分析：后台权限设计》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《Vega战队CEO发文称将会进行重大阵容调整》，感兴趣的同学可以点击进去看看。