1/12
角色权限设计的100种解决方案
下面笔者结合自己的几条权限设计经验，提供一些所谓的经验套路，希望各位设计师能够微笑着满足权限要求。
1、权限设计麻烦
设计师在设计时，往往会抽象出多个对产品有需求的角色。
根据不同的业务需求，限制的形式有很多种。需要注意的是，不能仅仅依赖后端的限制
相反，在前端显示明确的规则和适当的限制，以避免用户错误和沮丧。
3、权限的拆分与设计
通过RBAC模型可以很好的建立用户、角色、权限之间的关系。但是
实体之间是什么关系，“权威”这个抽象概念又是如何具体规划的？
这些都需要分析清楚，才能进一步设计出完整的权限体系。
首先你要知道，一般产品的权限由页面、操作、数据组成。页面和操作是相互关联的
您必须拥有页面权限才能在页面下分配相应的操作权限。 可以对数据进行添加、删除、修改、检查。
整体关系如下图所示：
1/12
8/12
因此，在设计之初，我们需要考虑未来可能在哪些方面进行角色区分，并尽量将其解耦、模块化。 对于技术来说，每个页面模块、每个操作最好采用独立的接口。 对于设计来说，需要保证即使所有角色因权限原因屏蔽了部分操作和数据后，页面和流程仍然能够流畅体验。
在保证初始设计支持后，在配置权限时需要注意以下几点：
1）判断是否支持前端配置
如果角色和权限比较固定的话，角色和权限的关系一般可以写在后端。 更改需要更改后端并重新上线。 这种情况适用于只有一个用户的系统，例如公司内部系统。
1/12
10/12
9/12
如果需要自定义角色或者不同用户场景下每个角色有不同的权限，则需要在“前端用户配置页面”体现角色的定义以及角色与权限之间的配置。 这种情况适用于自定义角色权限频繁变化的系统和租户系统。
2）拆分为基本单元并配置业务逻辑
一般来说，每个对象的“增、删、改、查”都可以看成是一个基本的权限单元。 例如，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为四个权限单元。 在技术和设计上，我们希望尽可能的解耦、模块化。
然而，业务层面的一些操作是集成的。 这些无法分割的权限建议打包成一个整体，在“前端用户配置页面”中提供配置。 例如：如果我们确定系统当前和未来的业务中，只有普通会员具有“人员管理”的查看权限，管理员具有操作权限游戏策划，那么“增、删、改”这三个基本权限单元就可以合并为“操作”权限进行配置。
3）页面权限优先于操作和数据权限
必须先配置页面模块权限，才能配置当前页面模块下的具体操作权限以及页面模块的数据显示权限。
4）查看权限优先于增删改查权限
11/12
8/12
一般情况下，必须先能够查看某个模块或操作，其他的增删改操作才有意义。 因此用户角色权限表设计，设计时应在获取查看权限之前限制其他权限的配置，或者在配置其他权限时默认授予查看权限。
5）角色与权限的各种关系
角色和权限之间的关系不仅仅是简单的“是/否关系”，还包括一定限制的操作和一定程度的数据访问。
以“人事管理”为例：
数据范围：用户有权限查看人员列表，但只能查看自己的团队；
数据边界限制（上限等）：不能添加超过20人等。
数据字段：HR可以查看人员列表中的职级、薪资等字段，其他角色只能查看姓氏。
姓名和电子邮件地址等字段；
(6)角色和权限的设计表达
在传达系统的权限设计规则时程序开发，设计者往往会用最主观、最直接的方式表达自己的想法，比如使用“当……用户角色权限表设计，那么……”的句型。 然而，一个平台涉及到的权限规则有很多。 当整篇文章以这种形式描述时，表达对象就会难以理解。
11/12
8/12
正确的描述方式：根据开发语言和技术模型的结果进行更清晰的表达。 将每个角色和权限单元绘制成一个网格，在每个交集网格中描述角色和权限的数据关系和限制。
如下所示：
4. 需要注意的提示
隐形管理员
在角色和权限可自定义的系统中，一般需要为系统的初始配置预留一个admin角色，用于添加第一批业务人员并配置基础角色。
有些系统允许上帝视角下admin角色的存在，并且可以在角色配置列表中显示为“超级管理员”。 有些系统不允许这个角色存在，所以可以将这个角色设置为不可见状态，只赋予维护系统的人员。
授予初始权限
12/12
对于允许用户自行加入的系统，需要设置一个或多个默认角色，有时可能只是
8/12
13/12
拥有最基本权限的“访客”角色。
初始权限还可以与用户已有的一些数据字段相关联，例如添加用户时获取的用户信息。
如果用户的职位是“设计师”，则直接赋予“设计师”角色的权限。
人事管理中的自我管理
在人员管理中，管理员角色在处理时需要格外小心。因为如果修改或删除自己的角色，系统可能没有管理角色，从而无法添加其他角色。
