2B系统总是不可避免地会遇到权限问题。 它不是核心业务，但却是不可或缺的，并且时刻影响着整个系统。 更可怕的是权限管理设计角色，不同的客户有完全不同的组织结构，而且功能的复用性很强。 低的。 有没有什么方法可以快速解决权限问题？
当我们一般谈论【权限】时，我们谈论的是功能权限和数据权限。 功能权限是指用户登录系统后可以看到哪些模块和页面，而数据权限是指用户在某个模块中可以看到多少条数据以及可以看到哪些数据。 下面分别介绍一下我对功能权限和数据权限的理解。
功能权限
在企业系统中，配置用户功能权限可以解决不同人员负责不同业务的需求，但如何实现快速配置呢？ 功能的粒度是模块级、页面级还是更细粒度？ 跨模块操作没有权限怎么办？
图1-1
RBAC模型
说到功能权限，就不得不说到RBAC（基于角色的访问控制）模型。 它的中文名称是基于角色的访问控制。 主要是将功能组合成角色，然后将角色分配给用户。 换句话说像素游戏素材，角色是功能的集合。 RBAC 有多个成员，但基本的 RBAC0 对于我们涵盖的系统来说已经足够了。 （想了解更多请点击RBAC权限管理汇总）
为什么要引入这个模型呢？ 请参阅以下示例：
企业A共有12个职能，需要创建100个用户，包括财务、人事、销售等。如果不引入RBAC模型，我们需要在每次创建用户时分配一个职能，即至少100次（每个用户只有一项功能）。 如果人数增加到1000人甚至10000人，并且一个用户可能有多种功能，那么操作会非常繁琐，如图：
图1-2
经过多次操作，发现分配给某些人的功能都是一样的。 例如，分配给A、B等10个用户的功能都是客户管理、订单管理、供应商管理的模块。 那可能吗？ 把这些功能模块打包分发给需要的用户怎么样？
这个包称为角色。 由于角色和功能的对应关系比较固定，所以在给用户分配权限时只能分配角色。
图1-3
因此，引入RBAC模型的意义在于：
用户与功能解耦，降低操作错误率； 降低功能权限分配的复杂度。
图1-4 图中，一个用户对应一个角色，但在实际场景中，一个用户也可以对应多个角色。
一些比较复杂的系统可能会涉及到RBAC家族的其他成员：RBAC1、RBAC3、RBAC97等，并逐渐看到诸如【用户组】、【角色继承】、【受限角色】等概念，但是引入模型太多了。 根据和调整，复杂度不会因为模型的增加而迅速降低，模型引入带来的边际效用只会越来越低。
更多角色问题请参考：角色权限设计100解
功能粒度
功能越多，操作越繁琐，复杂度越高。 因此，选择合适的功能粒度可以快速梳理权限问题，帮助用户提高工作效率。
功能的粒度一般从粗到细划分：模块级->页面级->接口级（接口级的功能权限是指哪个角色可以调用哪些接口）。
从后台角度来看：为了系统安全，代码肯定会在接口层面实现。 那么我们的粒度选择有何意义呢？ 当然是为用户降低成本、提高效率。 只是粒度越粗，用户操作越简单游戏素材，但灵活性越低。
非技术网站做到模块级别就够了，不然用户体验会让人哭。 对比下面两张图感受一下：
图1-5
功能优先
如果必须将权限细化到页面甚至界面级别，则应遵循优先级规则。 也就是说，只要分配了低优先级的功能，就必须先分配高优先级的功能。 否则会出现删除权限却找不到操作位置的尴尬情况。 （列表页有删除按钮，但没有分配查看列表页的权限）。 具体方法可以通过交互来解决。 例如，如果它检测到低优先级的功能被选中，它会自动帮助检查高优先级的功能，或者使用提示文本来帮助用户组合检查。
需要注意的是，不同的交互设计会导致优先级不同，因为有些按钮会放在列表中，有些按钮只会放在详情页上。 我们常用的优先顺序是查看详情 > 查看列表 > 添加、删除、编辑等操作按钮。
跨模块访问问题
有一个系统具有模块级别的功能权限。 模块A的页面有一个链接可以访问模块B的页面，只有模块A权限的用户可以点击该链接进入模块B吗？
这个问题有两种解决方案：
1.允许只有模块A权限的人通过链接访问模块B
这说明系统有一个隐含的规则：能够看到链接就意味着该用户拥有模块A和模块B的某些页面的功能权限。后端需要【自动分配】访问模块某个页面的权限B 给所有用户[具有模块 A 权限]。
2. 只有同时具有A模块和B模块权限的用户才能通过该链接访问。
这表明该链接是为拥有这两个模块权限的用户设计的。 即只有A模块权限的用户无法通过链接访问B模块。
这里需要根据实际业务为用户选择一种方法，但无论哪种方法，都可以通过交互和预定义的方法使操作变得更加简单。 比如选择第一种方案，那么初始化一个模块，具有A模块权限和B模块某个页面的角色，让用户可以随时选择。
数据许可
如果所有信息公开透明，就不需要控制数据权限。 但现实世界就是如此复杂，每个人需要看到和应该看到的数据总是不同的。 数据权限就是为了应对这些需求和规则而诞生的。
数据权限解决的是用户能看到多少数据、能看到哪些数据的问题。 例如，用户A和B都可以看到销售模块，但是A可以看到320条数据，B只能看到100条数据。 而A可以看到的320条数据包括B可以看到的100条数据。 这些都是由数据权限决定的。
数据权限与什么相关？
数据权限一般与企业的组织结构有关，组织结构分为树型和扁平型（还有更复杂的组织结构，这里不再解释）
图2-1 树状组织结构，每个部门都是一个节点
图2-2 扁平化组织架构
由于扁平化组织结构比较简单，需要注意的问题已经隐含在树形结构中，所以下面主要讲树形结构。
级别数
不同的企业层次有不同的深度。 如果系统支持无限级别，优点是通用权限管理设计角色，缺点是带来数据和可视化实现的复杂性，所以要具体问题具体分析。
如何在节点之间共享数据
图2-3
由于用户拥有的权限是功能权限和数据权限交叉定义的，因此这里假设G、A、B部门的用户都拥有用户管理和资产管理的功能权限。
目前节点间的数据共享方式有以下几种：
实际业务系统中定义数据权限时：
A。 选择以上规则中的一项或多项；
b. 根据业务定义上述【管理】：添加、删除、修改、搜索以及各种小功能的组合。
例如，如果选择父节点，只能【查看但不能编辑、删除、添加】子节点的所有数据，则图中用户G只能查看部门A的所有数据，不能编辑，删除，或者添加。 。
节点内用户存在上下级关系怎么办？
图2-4同图2-3
如果实际业务中用户A1是用户A2的上级，要求用户A1看到用户A2的数据，但用户A2看不到用户A1的数据怎么办？
如果只在节点级别（组织级别）指定数据权限，那么用户A1和用户A2看到的数据将是相同的。 因此，有必要再次引入职能权限的【作用】来解决人员上下级问题。
例如，如图2-4所示，系统选择的数据共享方式是：节点只能添加、删除、修改和查看自己节点的数据。 另外引入了角色规则：管理员可以对所在节点的所有数据进行添加、删除、修改、查看。 ，非管理员只能删除、修改和查看自己创建的数据。 那么如果用户A1的角色是管理员，A2是非管理员，则A1可以对部门A的所有资产进行增删改查，而A2只能对自己创建的资产进行增删改查。
扁平化架构
扁平化的组织结构比较简单，只有树形结构中的第三个问题。 请参阅树结构的问题3。
函数权限与数据权限冲突：跨模块数据【使用】问题
假设一个系统有两个模块：模型管理和设备管理。 操作系统的流程是先创建模型，然后创建设备。 如果用户只有设备管理权限，没有模型管理权限，创建设备时是否可以选择模型？
图2-5
这实际上是一个功能权限（接口级别）和数据权限整合的问题。 即用户在创建设备时是否有权限请求型号列表接口？ 列表中应显示哪些数据？
在功能权限方面：用户必须具有请求接口列表的权限，否则流程将无法进行。
在数据权限方面：有以下几种规则可供参考，您可以根据实际业务进行选择：
无论模型是哪个级别、谁创建的，都会显示在界面中（即模型数据在其他模块中使用时全局可见）； 只显示当前登录用户所属节点创建的模型； 只显示当前登录用户所属的节点及下级节点。 创建模型（扁平化组织结构不适用）； 只显示当前登录用户所属节点的父节点创建的模型（扁平化组织结构不适用）； 只显示当前登录用户所属节点Model的兄弟节点创建的模型（扁平化组织结构不适用）； 仅显示当前登录用户创建的模型。 综上所述，构建toB系统时需要考虑两类权限：功能权限和数据权限。 功能权限可以参考RBAC模型，通过引入角色、用户组等概念来降低复杂度。 但当系统用户数量庞大、功能极其复杂且粒度足够细时，复杂性就不可避免。 你只需要考虑是把复杂性交给用户、运维还是代码。 数据权限主要与组织结构有关。 组织结构的树形结构相对复杂，需要统一或模块化定义层级之间的数据共享问题。 在数据权限定义过程中，如果同一节点下出现【用户之间（上下级）层级问题】，则需要回到功能权限的【角色定义】来解决。 有一种跨模块[数据使用]问题，也可以看作是已建立的接口权限和可选数据权限的问题。
总之，当杨帆在角色权限的海洋里转来转去的时候，他总会想出一些原则和理论来帮助我们更快地转圈，有更大的成就感。
