前言：

市面上可参考的后台管理系统并不多，也无法参考竞品的后台，对于初出设计后台管理系统的同学来说，设计其中的基础功能，成为了一件困难的事情。

做了三个后台管理系统，才慢慢熟悉了基础架构和必备功能模块，于是梳理出来和大家一起分享。本文中提到的后台管理管理，仅适用于移动端（例如小程序/APP）的管理，不适配大型saas平台。

后台管理系统（下文中统称后台）中，比较核心的模块是权限模块的设计。我总结出一套通用方案，可供大家学习和借鉴优化。

首先，要清楚一些名词和定义还有模型，才能更好地理解权限系统。

一、定义解释与权限模型

• 用户：指系统的登录用户，可以理解为一系列的操作人员，例如运营同事小张，销售小王等；
• 角色：指用户在系统中担任的角色，是系统赋予用户的头衔，例如总经理、运营、测试等，多于岗位和职责挂钩，用于配置对应岗位的各类权限；
• 权限：能够访问某接口或者做某操作的授权资格；
• 菜单权限：指对应后台中的一级菜单/二级菜单的页面访问权限，比如订单管理-拼团订单列表；
• 操作权限：指后台对数据进行新增、删除、修改、查看、导出等操作的权限；
• 数据权限：指该角色可以查看或者操作的数据范围，例如销售人员录入了客户信息，那么每个销售只能看到自己创建的数据，不可以看到其他销售的数据，这是一种常见的数据权限范围。

介绍完名词的定义，下面讲解的是RBAC权限模型。

RBAC权限模型：RBAC，即基于角色的访问控制（Role-Based Access Control），是优秀的权限控制模型，主要通过角色和权限建立管理，再赋予用户不同的角色，来实现权限控制的目标。

利用该模型来配置权限，直接优点是角色的数量比用户的数量更少，先把权限赋予角色，即可完成权限的分配；再为用户分配相应的角色，即可直接获得角色拥有的权限。

交互设计的福音，只需定义有限的角色拥有哪些菜单权限即可。

二、功能设计

进入简单易懂的看原型做功能环节，稍有经验的产品经理，看了界面就应该知道这个功能大概是怎么设计了。此章节内容包括：账号管理、角色权限管理、菜单管理。

1. 账号管理

在我设计的系统里，融合的组织架构管理。

组织架构管理就不展开说了，就是对公司的架构进行设置，此处会影响用户的数据权限，因为用户的数据权限是根据组织架构的树来进行匹配，这个后文再详细讲解。

新建时，设置当前员工的账号，配置对应的角色。因为我们设计了微信登录和公众号推送消息给内部人员，所以需要绑定用户的微信号。

2. 菜单管理

菜单管理主要为前端人员使用，用于配置系统的菜单，包括菜单的层级，增删改等。此处不做过多解释。如果涉及到设计此需求，提出对应需求即可，前端会根据具体情况进行研发。

3. 角色管理

角色管理中，包括的整个权限模块的核心，菜单权限和数据权限。

配置菜单权限，即为配置用户的页面访问权限和操作权限。此处较好理解，在设计需求时，需要根据业务具体描述需要被权限控制的功能。

我一般是要求研发将页面中可以点击的按钮都做权限控制，这样后续权限配置就会比较灵活。

数据权限目前我遇到的业务场景需要包括：仅查看本人数据/查看本人及以下人员数据/查看本部门数据/查看全部数据/自定义数据。

1）查看本人数据

顾名思义，就是只能查看自己创建的数据。例如为了避免恶性竞争，企业中员工王五和肖六各自名下有不同的客户，所以他们在后台查询客户的时候，都只能查看自己名下的客户。

2）查看本人及以下数据

例如在组织架构中，你是一个小组的组长张三（图中左下角），下面有两个小弟A和B。那么配置完毕（需要在组织架构中将你配置为负责人），你可以看到你的数据加你小弟的数据。

3）查看本部门数据

你继续当张三，如果配置了查看本部门数据，则跟你平级的小组数据，你都可以查看。例如你可以查看小组1和小组2的全部数据。

4）查看全部数据

一般是总经办的权限，老板当然可以查看所有人的数据啦。

5）自定义数据

可以配置某个角色，查看某个具体的人员的数据，这个业务场景比较特殊，可能并不是很通用。例如，销售助理，可以查看部分销售人员的数据，进行工作检查。

三、其他权限

这里是指一些包含在业务中的特殊权限，比如字段的可见性。如果要控制权限到字段的颗粒度，就需要把每个功能页面的字段提炼出来，单独配置给角色。还比如一些敏感数据的可见性。

例如：某个用户的手机号对部分角色可见、部分角色加密。这个部分要单独设计在操作权限里，单独列出。