01 超简化版本-用户/权限模型
用户直接映射到权限。 这种设计的优点是简单直观，适合用户数量较少、功能相对简单的系统。 它的缺点也非常明显。 当用户数量增加时，维护成本高，可扩展性差。
系统页面演示：
02 进阶版-用户/角色/权限模型
如果系统用户和功能增多，为每个用户匹配单独的权限就会变得非常麻烦。 因此，将权限进行分类，形成“权限包”。 从用户的角度来看，对用户进行分类，将同一类型的用户固定到相同的角色，并授予他们相同的权限，会让操作变得更加简单。
系统页面演示：
03级版本-组织/用户/角色/权限模型
对于行政后台来说，人员往往是按级别来划分的。 例如，用户王舞是销售组长，他的组员是赵刘和孙琪。 王五需要看到赵六和孙奇的销售数据，可以进行赵六和孙奇的所有操作，而赵六只能看到自己的销售数据，进行与自己相关的操作。
本案例引入了两个新概念。 首先，用户权限可以细分为功能权限和数据范围权限。 其次，数据范围和函数权限都继承了层次概念。
所谓的功能权限比较容易理解，比如是否可以看到某个页面或者点击某个按钮。 数据权限稍微抽象一些。 比如在业绩报表模块中，从功能权限的角度，可以判断用户是否可以打开这个报表页面，但是不同的用户进来看到的数据是不一样的（王五需要查看赵六的销售额）和孙奇）金额数据，而赵六只能看到自己的销售数据，看不到孙奇的），是受数据范围控制的。
1.数据范围的继承
我们可以对用户进行分级管理，比如建立多级组织结构树，将不同的用户放置在组织结构的不同根节点上，实现多级用户的建立和管理。
1）如果用户级别比较简单（不超过三级），可以将层级关系融入到角色中。 例如，将用户分为三个级别：管理员-组长-组员。 管理员可以查看所有数据范围并拥有所有功能权限人物立绘，而群主可以查看群成员的数据范围并拥有部分功能权限（例如不能编辑用户），群成员的数据范围仅为数据他们负责并拥有部分功能权限。
我们可以允许队长在角色下绑定队员，并为不同的角色设置不同的数据范围读取方式。 管理员可以读取整个数据范围，组长需要读取组成员的数据，只能读取自己的数据。如果有兴趣，可以了解一下RBAC0/1模型。
2）对于用户层级较多的情况，建议采用多级组织结构管理模式。 首先建立公司的组织部门，然后将人员放置在组织结构树的不同节点下。 用户的数据范围是根据用户在组织节点中的职位以及是否是某个节点组织的负责人来确定的。
2、功能权限的继承
一般将字符分为不同的类别，就有所谓字符树的概念。
由此，我们得到了自由度更高但逻辑更复杂的权限管理。
当涉及到组织结构树和角色树时，需要考虑的场景就更多了，这些细节要根据实际的业务场景来制定。 例如：
组织成立和解散，员工可能会更换职位或者组织部门，所以必须考虑时间线的概念。添加很多验证逻辑，比如需要增加员工的进入和退出时间创作人，以及员工的时间在该部门的时间不能早于该部门成立的时间等。同一员工是否可以兼职，是否允许在多个组织中担任职务。 会出现互斥的情况（RBAC-2模型）。 例如，在实际业务中，不允许同一个人兼任发钞和验钞工作。 因此权限管理设计角色，在功能设计时必须考虑角色之间的互斥性。 通过配置Roles来实现用户和权限之间的映射关系。 不同权限之间有优先级。 比如刚才的例子中，互斥关系的优先级最高。
实体关系图：
系统页面演示：
上面分析的三种权限管理其实并没有好坏之分。 权限管理作为系统的基石，应根据系统目标用户的特点、后续发展方向、维护成本等综合评估，找到最适合系统的模式。
知识点总结 用户管理的核心是解决用户和权限的问题； 角色可以理解为一种用户，或者权限的集合权限管理设计角色，链接了用户和权限之间的关系； 权限可分为功能权限和数据范围； 复杂的继承关系，数据范围取决于用户组织结构树，功能权限取决于角色树。 将用户放置在组织结构树的不同节点上并分配角色，解决了功能权限和数据范围的问题；
作者: yingyingzhiyu; 公众号“yingyingzhiyu”持续分享B端产品设计经验，期待与朋友们交流讨论。
