角色权限管理类似于系统的基础设施建设。 虽然它不像其他核心功能那么重要，但却是不可或缺的一部分。 并且随着产品内容和逻辑的增加，角色权限处理的价值将会越来越体现。 出来。 本文将以我做过的一个角色权限设计为例，简单分析一下其中的逻辑，供大家参考。
由于公司有统一的域数据库来存储用户信息，包括加入和离开公司的员工的信息更新，所以我们这里的用户管理是根据现有用户组来控制角色权限（并且数据可以实时同步） 。 该模块的架构如下：
整个模块由用户管理，分为三个部分：
部门组织架构
在线显示各部门人员信息及相应人员名单。 这里同步公司域数据库数据，并且还显示当前在线状态。
角色权限管理
这里分为角色组的建立和相应权限的控制。 根据需要创建和添加角色组及其成员。 创建完成后，需要进行权限控制，包括功能权限、资源权限、数据权限、集成系统访问权限等。
权限申请管理
这里是用户经过权限控制后对非权限资源的权限申请处理以及相应的权限授予操作（权限审批结果会自动生成消息通知，与公告消息一致）
上面的组织架构和权限申请部分基本上都很容易理解。 逻辑比较复杂的是角色权限管理部分。 我们先看一个关系图：
做好权限管理有几个关键点：
在上面的案例中，我们的数据权限采用的是黑名单制度。 顾名思义，我选择谁不能看到哪些数据。 默认情况下，每个人都可以看到所有数据。 这个可以根据具体情况进行正向和反向设计。 例如，如果大部分可以查看，只有少数不可查看，那么使用黑名单会更方便； 如果大部分不公开，只有少数公开，那么白名单会更方便，视情况而定。 。
我们以前也有过这样的经历。 通常，被分配某种角色的人有权将私有表转换为公开可见的表，并且相应的删除操作是由当时构建的人完成的。 谁删除了该表，即使其他人具有相同的权限，也无法删除该表。
在一次无意的操作中，我们发现共同拥有此权限的人无法删除其他人创建的公共表。 我跑去告诉同事，这张表是他创建的，需要他删除。 然后我就去了洗手间，突然觉得这个逻辑有问题。 如果十个人创建了十张表，然后将其转换为公共表，那么如果这十个人离职，这些表就不能被这些账户删除（不包括开发同事从数据库中删除的表）。 情况，因为我们设计产品的最终目的是减少数据库操作，最大限度的方便使用，逻辑合理）
因此，我们团队在意识到这个问题后，立即进行了讨论并及时更新。 虽然也有可能是别人的表被表的所有者以外的人删除，但一般来说，第一，这种情况比较少见；第二，这种情况比较少见。 其次，相应的解决方案是将删除表的功能仅分配给一名高层管理人员。 作为成员，其他角色不能随意操作，所以通过这种方式进行控制。 总之角色权限表设计，保证权限控制的灵活性是首要原则。
实际情况其实稍微复杂一点，因为我们还涉及到可以删除私有表（所有人都可以使用的功能）和移动到公共表（被授予权限的部分人可以使用的功能，还有这个操作按钮）没有权限的人不显示）； 查看公共表（所有人都可以使用的功能）、删除公共表（部分被授予权限的人可以使用的功能，没有权限的人不显示这个操作按钮）等。本来那天预约的，但是在为了调整这一点，我向开发商明确表示，所有预约都在短时间内取消（捂脸）。
在上面的案例中，我们在一些阻塞场景下提供了权限申请的入口。 当用户点击申请时，后台会自动收到权限申请消息音乐，消息中显示申请人的基本信息、申请来源、申请时间、审批操作等。 （通过/拒绝），具体申请处理流程如下：
这方面比较让我欣慰的是我们的技术同事把权限激活做得比较智能。 即在申请权限时游戏图片，会先后生成两个action。 一是自动开放上述角色权限模块中的权限。 向用户申请激活相应的权限（包括功能权限、数据权限和资源权限），二是激活过程完成后向用户的消息账号发送申请反馈通知。 这两项任务完成后，即权限申请“通过”，整个过程基本在1秒之内完成。 当然，即使开放了权限，以后也可能会被收回，所以这方面的灵活性是毋庸置疑的。
正如开头所说，角色权限管理并不突出，但却是必不可少的基础设施建设。 如果同一个公司很多产品都涉及到这个领域，其实可以打包成一个相对通用的产品方案，避免重复发明轮子。
以上是我对之前做过的角色权限管理的理解。 当然，根据不同的产品和不同的复杂程度，角色权限管理可大可小。 希望能给大家提供一些想法角色权限表设计，也希望自己在以后的工作中能够继续这样做。 要勤奋。
一起努力吧！
生活中的小可爱们
摩羯座的工作狂
大家好，我是慕斯小姐~
