RBAC权限模型——餐饮实战篇

Tamil 2023-12-07 20:50:31

一、权限构成

常见的数据数据构成一般有三类，分别是：

页面权限：页面权限授权包含可查看页面授权以及页面可见字段授权，大多数情况下不需要页面可见字段授权的配置，系统默认所有字段可见。页面权限主要控制用户可以访问哪些页面以及页面上的哪些部分，比如底部的导航栏哪些可以查看。
应用权限：应用权限是指用户是否有权使用系统中的某个应用或模块，比如电商的生意参谋、营销推广等子应用是否有权访问使用，或者是否需要额外收费等等。
数据权限：数据权限指得是用户的数据读写权限，即用户可以查看哪些数据，可以处理哪些数据。

数据权限分配可查看的数据权限和可操作的数据权限，大多数情况下只需要配置可查看的数据权限，可操作的数据权限需要对一些操作按钮分配可操作的数据范围。数据权限可以分为以下几类：

本人：用户只能查看本人所关联的数据。
全部：用户可查看所有数据。数据权限的设置通常与组织架构相关，可以根据用户在组织架构中的位置来分配相应的数据权限。

二、实战案例分析

介绍了RBAC模型以及数据构成之后，进入本文的正题，下面这个APP如果是你负责这个产品，你会如何设计权限后台进行配置？

我们先对APP进行研究与拆分，然后结合我们的目的来规划后台。在规划之初你要问自己三个问题：我要给用户看什么页面？页面上的数据范围是什么？我要给用户用什么应用？

给看什么：目前APP结构主要分为底栏（一级分类），以及数据里的顶栏（二级分类），所以我需要针对每个人配置页面权限，通过权限控制用户可以访问哪些页面，这里也做了组织架构配置，没有截图展示，具体根据使用场景进行设计。
数据范围：因为公司角色较多，且每个人所管辖的区域范围不同，所以我需要针对每个人进行区域数据权限配置。
给用什么：在工作台中，每个人的职能不同，所需要使用的应用频次也不同。所以我需要针对每个人配置应用权限。

三、实战案例（用户组设计）

1. 用户组设置

在理论篇中我们说到，如果您产品的组织架构比较复杂，且后期不想通过每个人物逐一赋能角色话可以采取用户组的方式进行分类。

新建用户组：名称（必填），备注，关联。具体根据产品情况进行字段配置。这里设计了一个关联功能。因为我希望人员组织架构的入离调转自动同步到用户组，不用手动增删改查。而且人为的工作方式不仅容易出错率最高且效率极低。

2. 用户组列表页

当用户组配置完成之后，我们进入列表页可以对用户组进行编辑、角色绑定以及删除，值得一提的是这里的删除我做了条件（当用户组内有员工时不允许删除），同样当员工有门店绑定时也不允许移除员工。这里员工配置做了三种方式：系统同步、手动同步、手动添加。

因为我们公司的数据权限是到人的，我相信很多餐饮公司的权限也是如此，所以我将数据权限（配置门店）并没有放到角色配置里，而是单独拿出来放在了列表，这样就可以针对某个人进行具体的权限配置。

看到这里你可能要问，那每次添加一个人我都要配置一次数据权限，这部分的运维工作量岂不是很大？确实如此，但是我们公司的门店维护是由各个分公司或者部门进行独自维护，同时有可视化的调整工具，之后数据同步到列表，可能会有个别不在配置场景里的才需要人工处理。所以这部分的工作量可以忽略，毕竟公司的不同阶段，对于人效的提高上也会有不同的处理方式。

3. 用户组配置门店（数据权限）

这部分我设计了两种配置方式，按区域和按门店。

按区域：主要是针对每个人所负责的区域进行划分，与公司业务对齐，保持统一的用户习惯。
按门店：更加灵活的配置方案，比如我们的大KA，会有专门的客服进行一对一处理，那么我搜索加盟商的名字将他所关联的门店配置给客服就可以。当然也有很多其他的场景，作为一个兜底方案也是不错的选择。

四、实战案例（角色设计）

1. 角色设置

新建角色：名称（必填），备注。具体根据产品情况进行字段配置。

角色设计比较常规，新建之后，对应的角色有2个权限配置，分别是账号权限和页面权限。

页面权限：这里我将页面权限与功能权限做了整合，所以在一个页面上完成即可。
账号权限：因为这套权限系统，后期肯呢个会整合其他产品进行权限统一管理，所以这里我单独设计了一个账号权限列表。同时可以针对每个角色进行登录控制。

2. 角色关联

设置好角色之后，我们将用户组与角色相关联即可。这样我们用户组内的所有员工都将与该角色进行绑定，从而达到APP访问后的需求。

五、总结

通过实例我们已经详细了解到，我们新建用户组之后，通过系统自动添加员工。后期只要调整角色的权限关联用户组即可满足业务的页面、应用、数据相关的权限分配。

因为每个公司的业务与系统都是唯一的，案例只能作为产品设计的参考，具体的设计方案应该结合公司现状与需求才是。大家看完文章之后要是有不同的想法，欢迎一起交流共同成长。