网易UEDC – 蒋蕊遥 ：文章结合自己的几次权限设计经历，提供些所谓经验套路，希望各位设计师从此微笑迎接权限需求。
一、令人头疼的权限设计
设计师在进设计时，常常会抽象出品有诉求多个色，再依据色特性去梳理使用场景并设计。
当角之间的使用场不冲突，不需要隔离时，我们综合考虑角的使用场来设计决方案。比：网易云音乐同时为需要听歌和听电台的用户，提供所有的功能。
当角的使用场完不重叠、流程对立时，我们设计完独立的两套系统，滴滴的司机端和乘客端。
但除以上两种情况，在大数 B 端产品中，基流程正、信息安等因素考虑，各个角的使用场是部分通用，部分隔离的，时就需要引「权系统」。
设计师有时对角权系统有一丝畏难情绪。
- 为色权限系统配作为个常后台管理功能，在竞品调研过程很难过上帝视去解剖其逻辑，自己琢磨又较难透彻；
- 另一方面对角权系统，做并不能代表设计能力有优，但一旦没做就导致整个流程不通、产品崩溃。所以设计师常对权系统望而却步。
以下笔者几权限设计经历，提供些所谓经验套路。
二、基于技术模型进行设计-RBAC模型
进设计前，最好能够理解技术模型。在业界接受度较高功能权限模型是 RBAC（Role-Based Access Control）模型，其基本理念是将「色」这个概念赋予用户，在系统用户与权限过色进关联，以这样法来实现灵活配。以下模型与设计相关几做下简单介绍。
1. 基本RBAC模型
如没有色概念，系统加入个用户，需要为这个用户配遍权限，下图是 wiki 接为用户权限管理，可以看出管理成本巨大。
而引入「色」概念后，如下图即是 RBAC 模型最基本模型：用户与色可为多或多多关系，个用户色为多多时，前用户权限是多个色并。
此时需要为色赋予权限，能够大大减轻管理负担，时将用户与权限解耦，提供更大灵活性。
2. 引入用户组概念RBAC模型
在大型平台应用上，试想如用户量上，新增个色时，可能需要为大量用户都分配遍新色，工程量仍然巨大，此时即可以引入用户组概念。如部分用户使用场景是相致和基础，我们可以把这些用户打成个组，基于这个组象进色和权限赋予。
同理果权时也存在一样的问题，处理方式是引权组的概念，将使用场相对固定的一组功能或权打包成组赋予角。但是一般来讲一个系统中权功能的量是相对有和控的，所以际应用中对权组的使用少。
下图所示为 mac 系统中运行添加用户组，并以用户组为单位置权。
需要注意的是即使有用户组或权组的存在，也以允许用户或权与角直接关联，个以视具业务情况而定。
3. 角继承的RBAC模型
在一个业务场中，果角需区分：设计主管、设计组长、设计成，并且管理方式为向下兼容时，则需使用角继承的 RBAC 模型。上角继承下角的部权，且额外赋予权。
此时除对角进行定义，还需要管理角间的关系，通关系来现角的级关系，从而达到继承权的效果。角的继承关系主要有两种：树形图和有向无图。
继承关系常常来源司团的组织结构，此时常将角与组织结构进行关联达到继承角模型的效果。下图所示的赵同学，其角是「三级团负责人」，与其并列的小组中有个「三级团负责人」的角，但依附左的组织结构树，各级负责人仅有查看和操自己下属子节点的权。
4. 限制RBAC模型
在个品或系统，部分色可能是需要隔离、不允许被时赋予个。跟大家熟知不能既是「运动员」又是「裁判员」个理。
因此，对众角中的一组，只能是单选的关系，但组角之间以共同存在。下图中，一个用户以既为设计师又为管理，但在设计师角组中仅能被赋予一个角，在管理角组中也仅能被赋予一个角。
此外，还有能是数量上的，比一个产品组中必须有且只有一个管理，不允许删除或分管理角，仅允许将负责人角变更。
的模型不仅仅对分程产生影响，有时即使拥有种角，因为不同的角对同一个功能的使用方式或数据产生冲突，所以使用时也需要进行。下图所示为同一时间仅允许以一个身份登录。
根据不同的业务需求，的形式很。需要注意的是不能仅依赖端，而是要在前端展示清晰的规则和恰当的，避免用户出错和沮丧。
三、权限的拆分与设计
通 RBAC 模型已经能够很的搭建用户、角与权之间的关系。但具是什么样的关系，以及「权」个抽象的概念具何规划？
这些都需分析清楚能一设出完善的权限系统。
首先需要知道，一产品的权限由页面、操作和数据构成。页面操作相互关，必须拥有页面权限，才能配该页面下对应的操作权限。数据可被增删改查。
整体系如图示：
因此，在设计之初我们就需要考虑到未来可区分角色的地方，尽量解耦、模。对于技术来说，每一个页面模、每一个操作都最好使独立的接口。对于设计来说，需要保障有角色因为权限而屏蔽掉分操作和数据后，页面和流程仍体验流畅。
保证初期设计支持后，配权限时，需要注意以下几：
1. 确定是否支持前端配
如色和权限相固定，则般将色与权限关系可以写在后台，改动时需要后端变更新上线。这情况适用于公司内部系统等有个使用主体系统。
果需要自定义角或者每个角在不同使用者的场下有不同的权，则需要将角的定义、角与权之间的置现在「前端用户置页面」。种情况适用有频繁变动的自定义角权，和有租户系的系统。
2. 以基单元拆分，以业务逻辑置
一般将每个对象的「增、删、改、查」各自为一个基的权单元。打个比方，在「人管理」中，查看人列表、添加人、删除人、编辑人信息最拆分为4个权单元。在技术和设计上，我们希望能尽量做到耦和模块化。
但业务层面些操作却一体的。这些不能拆的权限「端用户配置页面」中建议打包一整体提供配置。例如：如果我们确系统的未业务中，仅分普通员「人员理」的查看权限，理员操作权限，则可将「增、删、改」三基本权限单合并「操作」权限行配置。
3. 页面权限优先于操作数据权限
必须配置了页面模块权限后，能配置当页面模块下具体的操作权限，以及页面模块的数据展示权限。
4. 查看权限优先于增删改权限
常况下，一先能查看某模块或操作，其它的增删改操作意义。因此设时，应获取查看权限限制其它权限的配置，或者配置其它权限时默认赋予查看权限。
5. 角色与权限的多种关系
角色与权限的关系不仅单纯「/否关系」，还包括以某种限制行操作，以某种程度访问数据。
例如在「人员管理」中：
- 数据范围：用户拥查看人员列表的权限，但仅能查看自己所的团队；
- 数据边界限制（上限等）：添加人员不能超过20个等。
- 数据字：HR 查看人员列表中包括职级、薪资等字，它角色仅查看姓名邮箱等字；
6. 角色与权限的设表达
传达一系统的权限设规则时，设师常常习惯用主观直接的方式表达法，如用「当……时，就……」的句式表达。但一平台中涉及的权限规则非常多的，当通篇以这样的形式描述时，表达对象将很难理解。
正确的描述方式：更清晰的是基于开发的语言，和术模型的结果进行表达。将各角色权限绘制成网格，每个交叉点网格中描述该角色权限的数据关系和限制。
如图示：
四、需要注意的Tips
1. 隐形的admin
可自义角色权限的系统中，一般需预留一 admin 角色行系统的初始配置，用于添加首批的业务人员配置基本的角色。
有的系统中允许存在上帝视角的 admin 角色，则其可以作为「超管理员」显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色置为隐形的状，仅赋予维护系统的工作人员。
2. 初始权限的赋予
对于允许用户行加入的系统，需要定一至多个默认的角色，有可以是仅有最基础权限的「游」角色。
初始权限还可与户既有的某些数据字进行联，如添户时获取到户的岗位为「设计师」，则直接赋予「设计师」角色的权限。
3. 人员管中对自己的处
在人员管中，管员角色处自己时需要额外注意。因为如果修改或删除了自己角色后，可导致系统没有管角色，从而无法添他成员和正行。设计时可添判断，当自己为唯一管角色时，禁止编辑和删除。
4. 无页面权限的示
虽然可通过页面权限限制直接隐藏当前户没有权限的页面，但除户获取到权限外的 url 地址。当户意外访问到没有权限的页面时务必供「无权限」的示，避免户认为系统 bug。
总结
总结一，整个权限系统设计就是定义各个节点和节点间系的过程。
节括：
- 户；
- 用户组；
- 角；
- 角色组；
- 权限（页面、操作、数据）；
- 权限组（页面、操作、数据）。
关系包括：
- /否关系；
- 继承关系；
- 限制系（互斥、范围限制、边界限制、字限制……）；
梳理清楚所有逻辑后，通过灵活定义节点和组各节点之间的关系，便能够轻完成角色权限设计的100种解法。
欢迎关注作者「网易UEDC」的公众号：
图片素材作者：Berin Catic
浙公网安备33011002017549号