系统权限功能设计
RBAC模型
目前，RBAC(Role-Based Access Control)模型是一种被广泛接受的功能权限模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员来获得这些角色的权限。这大大简化了权限的管理。在组织中，角色是为完成各种任务而创建的，用户根据其职责和资格被分配相应的角色。用户可以轻松地从一个角色分配到另一个角色。可以根据新的需求和系统合并赋予角色新的权限，也可以根据需要从一个角色中回收权限。
1.角色的角色
如果没有角色的概念，用户直接对应权限会更灵活，但是后台的数据表设计会变得复杂，运行成本高，容错性变差。
引入“角色”概念后，用户与角色的关系可以是多对一，也可以是多对多。当用户的角色是多对多时，当前用户的权限是多个角色的联合。这时候只需要给角色赋予权限，可以大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，提高整个设计的容错性。
2.介绍用户组
在一些大型平台上，如果用户数量较多，在添加角色时，需要给大量用户分配新的角色，工作量巨大。这时候我们可以引入用户组的概念，把这些用户拉到同一个用户组中，然后给整个用户组分配角色，这样就大大减少了角色分配的工作量。
同样，权限多了也会有同样的问题，给角色设置权限的时候需要大量的操作。这时可以考虑引入权限组的概念，将与角色关联性强的权限进行分组，从而减少赋值时的工作量。在现实中，权限组的使用相对较少，因为系统中的权限一般都是有限的。需要注意的是，即使存在用户组或权限组，也可以允许用户或权限与角色直接关联，这可能取决于具体的业务情况。
下图显示了添加一个在mac系统中运行的用户组，并按用户组配置权限。
3.角色继承的RBAC模型
在一个业务场景中，如果需要区分角色:设计主管、设计团队领导和设计成员，并且管理模式是向后兼容的，那么应该使用角色继承的RBAC模型。上级角色继承下级角色的所有权利，并且可以被赋予额外的权利。
这时，除了定义角色，还需要管理角色之间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种:树形图和有向无环图。
传承往往来自于公司团队的组织结构。此时，角色往往与组织结构相关联，以达到继承角色模型的效果。如下图所示，赵的角色是“三级组长”，与他并列的组中有几个“三级组长”，但都依附于左边的组织结构树，各级领导只有查看和操作下属子节点的权限。
4.受限RBAC模型
在一个产品或系统中，有些角色可能需要隔离，不允许同时给一个人。众所周知，“不能既当运动员又当裁判”。
因此，对于一组多个角色来说，只能存在单选关系，但多组角色可以共存。如下图所示，一个用户既可以是设计师，也可以是管理员，但是只能被赋予设计师角色组中的一个角色和管理员角色组中的一个角色。
此外，这些限制可能是数量上的。例如，一个产品组中必须只有一个管理员，并且不允许删除或重新分配管理员角色，只能更改负责人的角色。
受限模型不仅影响分配过程，有时即使有多个角色，也需要限制使用，因为不同的角色会与同一函数或数据的使用发生冲突。如下图所示，一次只允许一次登录。
根据不同的业务需求，有多种形式的限制。需要注意的是，我们不应该仅仅依赖后端的限制，而应该在前端显示清晰的规则和适当的限制，以避免用户的错误和沮丧。
第三，权限的划分和设计
通过RBAC模型很好地建立了用户、角色和权限之间的关系。但到底是一种什么样的关系，如何规划“权威”这个抽象的概念？
这些都需要分析清楚，才能进一步设计出完善的权限体系。
首先你要知道一般产品的权限是由页面、操作和数据组成的。页面和操作是相互关联的，必须有页面权限才能在该页面下分配相应的操作权限。可以添加、删除和检查数据。
总体关系如下图所示:
所以在设计之初就需要考虑未来可能区分角色的地方，尽量去解耦，模块化。对于技术来说，每个页面模块和每个操作最好使用独立的接口。对于设计来说，需要保证所有角色因为权限的原因，屏蔽了一些操作和数据后，仍然能够体验流畅。
确保初始设计支持后，在配置权限时应注意以下几点:
(1)确定是否支持前端配置。
如果角色和权限相对固定，一般可以在后台写角色和权限的关系，需要在后端修改，重新上线。这种情况适用于只有一个用户的系统，例如公司内部系统。
如果需要自定义角色或者每个角色在不同的用户场景下有不同的权限，需要在“前端用户配置页面”中体现角色的定义以及角色与权限之间的配置。这种情况适用于用户自定义角色权限经常变化的系统和租户系统。
(2)按基本单元拆分，按业务逻辑配置。
一般每个对象的“增加、删除、修改、查询”都可以看作是一个基本的权限单元。比如在“人事管理”中，查看人员列表、增加人员、删除人员、编辑人员信息，要分为四个权限单元。在技术和设计上，我们希望尽可能的去耦合和模块化。
但是在业务层面，有些运营是整合的。这些不可分割的权限建议在“前端用户配置页面”打包成一个整体来提供配置。比如我们确定在系统现有和未来的业务中，只有普通会员有查看人事管理的权限，管理员有操作的权限，我们就可以把增加、删除、修改这三个基本权限公司合并到权限中进行配置。
(3)页面权限优先于操作和数据权限。
必须配置页面模块权限，才能配置当前页面模块下的具体操作权限和页面模块的数据显示权限。
(4)查看权限优先于添加、删除和修改权限。
一般情况下，首先要能查看某个模块或操作，其他的添加、删除、修改操作才有意义。所以在设计的时候，应该在获得查看权限之前限制其他权限的配置，或者在配置其他权限的时候默认给查看权限。
(5)角色和权限之间的各种关系
角色和权限的关系不仅仅是简单的“是/否关系”，还包括有一定限制的操作和一定程度的数据访问。
例如，在人员管理中:
数据范围:用户有权查看人员列表，但只能查看自己的团队；数据边界限制(上限等。):不能超过20人。数据字段:HR可以查看人员列表中的职级、薪资等字段，其他角色只能查看姓名、邮箱等字段；
(6)角色和权限的设计表达
在传达一个系统的权限设计规则时，设计者往往习惯用最直接、最主观的方式表达自己的想法，比如“当……”这句话。但是一个平台涉及到很多权限规则，当整篇文章都用这种形式描述时，表达对象会很难理解。
正确描述:更明确地说，它是基于开发的语言和技术模型的结果来表达的。将每个角色和权限单元绘制成一个网格，每个交集网格描述了角色和权限的数据关系和限制。
如下图所示:
四、需要注意的小技巧
1.隐形管理员
在角色和权限可定制的系统中，一般需要为系统的初始配置预留一个管理员角色，用于添加第一批业务人员和配置基本角色。
在某些系统中，上帝视角的admin角色是允许的，因此可以在角色配置列表中显示为“超级管理员”。在某些系统中，这个角色是不允许存在的，所以可以将这个角色设置为不可见状态，只授予维护系统的工作人员。
2.授予初始权限
对于一个允许用户自己加入的系统，需要设置一个或多个默认角色，有时可以是“游客”角色，只有最基本的权限。
初始许可也可以与用户的一些现有数据字段相关联。例如，添加用户时，如果用户的职位是“设计师”，则直接给出“设计师”角色的权限。
3.在人事管理中把握自己
在人事管理中，管理员角色在与自己打交道时需要格外注意。因为如果修改或删除自己的角色，可能会导致系统没有管理角色，无法添加其他成员，无法正常运行。设计时可以添加判断，只有管理角色时禁止编辑删除。
4.无页面权限提示
虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但是不能排除用户获取权限之外的url地址。当用户不小心访问了一个没有权限的页面，一定要提供“没有权限”的提示，避免用户认为系统是bug。
最后
综上所述，整个权限系统设计就是定义各个节点以及节点之间关系的过程。
节点包括:
用户；用户群；角色；角色组；权限(页面、操作、数据)；权限组(页面、操作、数据)；
关系包括:
是/否关系；继承关系；限制关系(互斥、范围限制、边界限制、领域限制...)