2023年B端平台权限体系设计：RBAC模型的技术实现逻辑

B端平台权限体系设计：RBAC模型的技术实现逻辑在以往多个0~1大型数字中台项目中，底层权限体系是我最关怀的，也要求产品经理和开发同学、尤其是后端开发必需熟识后方可进入产品开发项目。

RBAC模型给了B端产品特别简单理解的权限方法，平台中也有许多RBAC相关的文章介绍。本篇重点介绍实际的技术实现过程，供大家参考，便利B端产品经理与开发同学的沟通，避开走弯路（曾经3个项目在此处折损颇多）。

一、权限体系的基础介绍

权限体系的要素有：业务组织、角色、用户和权限、页面、视图。

组织、角色、用户是基于业务变化可即时调整的。权限是最底层属性，由开发人员基于业务需求开发实现。权限约束的对象是后台的详细实例。依据数据接口平安需要，可设计专用的接口权限。权限分功能权限（含菜单权限）、组织权限、数据权限。页面、视图是系统根据业务配置、给对应用户呈现的内容。具体的权限体系说明，可参考《成熟CRM系统的权限体系解析》一文。

二、对RBAC模型的深度理解

RBAC（基于角色的权限掌握）模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地给予用户权限（如下图），从而达到用户和权限解耦的目的。

RBAC模型强调了用户、角色、权限间的关系，但在B端业务应用中是不能脱离业务部门存在的，因此4者必需建立关系。除了以上4张表外，后台还需记录用户、业务部门、角色的关系表，如下图：

1.成熟业务平台中对业务记录的基础要求

成熟ERP、CRM平台中权限体系特别严密，对业务记录有严格的要求：即单条业务记录中必需有业务记录的Owner和Owner所属的业务部门。因此，业务记录必需有7个基本字段：创建人、创建时间、最终修改人、最终修改时间、Owner、Owner所在的业务部门+状态（启用/停用），当Owner发生变化时，Owner所在的业务部门同步更新。

只有如此，才能保障组织权限的严格掌握，其实现规律：根据当前用户所在的组织和角色的数据范围来从数据记录中的Owner所在的业务组织来猎取的。加载可见数据后，再依据当前用户的编辑等权限进行前端的功能按钮掌握。

举例：张三是销售经理，查询权限是观察部门全部销售顾问的客户数据，修改权限是个人的。在猎取客户列表时，部分客户的修改按钮是高亮的（他个人的客户）、部分客户的修改按钮是置灰的（不是他的客户，是其他销售顾问的）。上图中，客户数据在线索中心中，其他业务中心的业务数据类似处理。

2.权限体系如何配置和规律实现的呢？

权限配置属于基础设置部分，一般由超管用户设定不同角色的权限，示例：

这样的权限配置实际上需要前后端商定的，采纳统一的权限码来协同掌握，使用excel表等其他方式商定菜单/功能权限、数据权限和对应的权限代码。示例：

留3个需要大家思索的问题：

组织权限是个人级、全部和本部、本部及以下的处理方式一样吗？假如一个人拥有多个角色、且不同角色的组织权限的级别不同，怎么处理？有功能权限就肯定可以处理业务记录吗？三、更简单应用：房产销售中的业务组织+项目组织

在房产销售业务中，会有业务组织，也会有项目组织及项目相关的业务数据，如：一个楼盘就是一个项目，这个项目上产生的线索归属于项目，客户归属于整个体系，进展的渠道公司也是归属于整个体系。

业务人员会在充当不同业务角色和项目角色，简单的如一个人同时在多个业务组织中、多个项目组织中，比如张三在BJ城市小区中任项目助理（拥有整个小区中的线索数据查看权限），同时在A项目任销售一组经理，B项目（非BJ城市小区）中任销售二组的案场顾问。此用户在点击线索列表时（项目外），看到的是BJ城市组织下的线索+A项目销售一组的线索数据+B项目中归属自己的线索。

这样的结果，就需要业务记录中既要有业务组织ID、还要有项目组织ID。

四、扩展学问：各类平台中的组织

行政组织：HR、OA等使用的行政组织，组织架构清楚。财务组织：财务预决算使用的组织，比如行政组织中有1~5级，但在财务体系内直到3级，那4、5级组织对应的财务组织就是3级。业务组织：业务运营的组织架构，与行政、财务组织类似，但会不同。举例：董事长下CEO、CEO下CMO+CFO，但业务系统中会将董事长、CEO、CMO、CFO均放在公司顶级组织里，甚至财务会计、BP均会放在公司这层。虚拟组织：常用于区域管理组织或职能组织，比如