角色权限管理类似于一个系统的基础设施建设，重要程度虽不及其他核心功能，但却是必不可少的其中一环，而且随着产品内容和逻辑的增多，角色权限处理发挥的价值会日渐体现出来。本文将以我做过的一个角色权限设计为例，浅析其中的逻辑，供大家参考。
由于公司有统一的域库存储用户信息，包括入职离职人员的信息更新，因此我们此处的用户管理是在已有用户群（并且可实时同步数据）的基础上进行角色权限的把控。此模块架构如下：
整个模块为用户管理，下分三块分别是：
-
部门组织架构
所有部门人员信息的在线展示以及对应的人员列表，此处同步公司域库数据，附加了当前在线状态的显示
-
角色权限管理
此处分为角色组的建立以及对应权限的把控，角色组以及所属成员按需创建和添加，建完之后对应做权限的控制，包含功能权限、资源权限、数据权限、集成系统的访问权限。
-
权限申请管理
此处是针对权限管控后，用户对无权限资源进行的权限申请处理以及对应的权限赋予操作（权限批复结果会自动生成消息通知，与公告消息相通）
上述组织架构和权限申请部分基本很容易理解，逻辑相对复杂一些的当属角色权限管理这部分，先看一张关系图：
做好权限管理有以下几个重点：
在上述案例中，我们的数据权限采取的是黑名单制，顾名思义就是我选择谁不能看到哪些数据，默认情况下是所有人可以看到所有数据，这个可以根据具体情况进行正反向设计。比如大部分都是可看的，不可看的是少数，那么就用黑名单方便一些；如果大部分都是不公开的，只有少数是公开的，那么白名单会更方便一些，因情况而异。
之前我们在做的过程中有过这样的一次经历，一般被赋予了某个角色的人员具有把私有表转为公共可见表的权限，而对应的删除操作，当时开发则做成了谁建的表谁删除，其余人即使有同样权限也不能进行删除这样的模式。
在一次不经意操作中我们发现共同拥有这个权限的人删除不了别人建的公共表，我跑去告诉同事说这张表是他建的，需要他删除，然后我就去了洗手间，但顿时感觉这样的逻辑存在问题，假使十个人建了十张表然后都转为公共表了，那么如果这十个人离职了，这些表还非这些账号不能进行删除操作了吗（不包含开发同事从数据库删除的情况，因为我们设计产品的最终目的就是减少进行数据库的操作，最大化方便使用并且逻辑合理）
因此意识到这一问题后，我们小组立即进行了讨论并且及时做了更新。虽然这样也存在不是表的主人删除他人表的可能性，但通常来说，第一，这样的情况相对较少；第二，对应的解决方案是可以通过把删除表的功能只赋予一个最高管理员，其余角色不能随意操作，这样来管控。总之要保证权限把控的灵活性，这是第一原则。
实际情况其实更复杂一点，因为我们还涉及私有表可删除（所有人都有的功能）、可移动到公共表（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）；公有表的查看（所有人都具有的功能）、公有表的删除（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）等，那天本来约了人，但为了调这个并和开发讲清楚，赴约都临时取消了（捂脸）。
在上述案例中，我们在部分屏蔽场景中提供了权限申请的入口，当用户点击申请后，会自动在后台接收一条权限申请的消息，上面显示申请人基本信息、申请源、申请时间以及批复操作（通过/拒绝），具体的申请处理流程如下图：
