后台系统的权限设计

权限设计通常隐藏于后台系统深处，以至于我们说起来都知道，但是在真正面对复杂的业务需求和逻辑关系，又有些抓瞎。

这篇文章是我对之前权限设计的一次复盘，希望在自己重新梳理的同时，也能给其他小伙伴带来一点想法。

权限系统设计的需求背景

业务流程复杂化：

随着业务越来越复杂，之前一个订单只需要一名销售跟进，现在却需要五个销售协同完成一个订单的流程（每个销售负责其中一个流程）。

此时我们就可以通过权限系统，分别赋予五个销售处理各自流程的权限（比如销售A只有录入意向订单的权限，销售B只有补充客户信息的权限，等等），这样每个销售都只能看到流转至自己手上的信息，将复杂的流程简单化。

信息敏感：

当同级部门不止一个时，便会在同一公司内产生竞争关系。例如，销售1组辛苦挖掘的用户数据并不想被销售2组看到。

权限系统可以设置不同部门的数据彼此独立，即便是各组组长也无法互看对方数据。

操作安全，权责明确：

在一个大型系统中，一个误操作产生的后果可能是非常严重的。

权限系统的存在最大程度上避免了这类问题——只要是界面上出现的功能，都是可以操作或不会产生严重后果的。

页面简洁：

如果系统没有进行权限管理，那么每个帐号登录后看到的界面都是一样的，充斥着各种与自己无关的，冗余的信息，甚至还需要专门培训，花费巨大的成本去学习。

经过权限系统的管理，每个帐号登陆后只能看到和自己有关的信息，可以更快速地理解自己工作范围内的业务。

权限系统的基本构成

权限系统主要由三个要素构成：帐号，角色，权限。

帐号是登录系统的唯一身份识别，一个账号代表一个用户。由自己注册或系统管理员统一注册分配。

角色，为账号批量分配权限。在一个系统中，不可能为每个帐号订制权限，所以给同一类帐号赋予一个“角色”，以达到批量分配权限的目的。

权限又分为操作权限，页面权限和数据权限。

其中操作权限指的是用户可以进行的操作，例如是否可以新增、删除、编辑等。页面权限指的是可以看到的页面。数据权限指的是可以查看数据的范围。

简单范例如下：

权限系统设计实例

实例背景

这是一个订单管理系统，销售、客服等角色通过系统完成整个订单的流转。

系统使用人数众多，等级复杂，有大量的销售团队存在同级竞争关系。

帐号管理

当前案例创建帐号的流程为：管理员在系统中新增帐号，用户自行通过邮箱激活。默认角色为“职员”，只分配最基础权限。

为了减少管理员的工作量，同时也支持通过excel上传，可以按照模版规范excel格式。

角色管理

当前案例中的角色就是“职位”，不同“职位”的用户，有着不同的权限。

角色管理的入口在“权限管理”页面，只具有基本的新增角色，编辑角色，删除角色，以及添加角色描述。

通常主流后台系统还会有复制角色等功能，复制角色是指：在新创建一个角色的时候，先选择一个已有的权限相似的角色，然后再修改新角色的权限。这样避免了权限太多的情况下，每个新角色都必须重新设置的繁琐情况。

权限管理

在实际设计中，很多系统会选择将页面权限与操作权限合并为功能权限，比如当前案例：

每一个页面有一个总开关，打开则意味着分配了页面权限。针对页面内所有的字段，有增删查改这四种主要的操作权限。如果对页面内某些敏感字段需要进行单独的操作权限设置，可以打开高级设置，进行字段级的操作权限配置。如下图：

在当前案例中，在有多个小组同级竞争的情况下，仅仅通过职位无法满足数据权限分配的需求，所以我们引入“部门”，以保证在同一级别的销售小组中，彼此信息保密，公平竞争。

另外，更高级别的部门，例如城市经理，甚至总经理，是理应有权限看到自己所负责部门以及下级部门的所有数据的。

所以“部门”这个权限组有了等级划分，根据等级进一步分配数据权限。例如，基层销售只能看到本人的数据，销售组长可以看到本部门的数据，总负责人可以看到本部门及下属部门的数据，总经理可以看得到全部数据。

部门的等级划分我们放在了公司设置页面，作为公司组织架构的介绍。

写在最后

权限系统的基本结构就是这样，但是现实中的权限设计却千差万别。

理解清楚基本概念，还要结合实际需求，去设计独一无二恰到好处的权限系统。也可以多参考些主流后台系统的权限设计，了解下类似的问题，别的系统是如何解决的。

一个小Tip：比起不厌其烦地去注册试用各种后台系统，不如直接去官网找帮助文档，有些简直详细到可以当prd了。

欢迎一起交流后台系统相关的设计思考～

8.7补充：昨天网易UEDC新发了一篇关于权限设计的文章，觉得梳理的非常清晰。推荐～

角色权限设计的100种解法