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

在以往多个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个需要大家思考的问题：

1. 组织权限是个人级、全部和本部、本部及以下的处理方式一样吗？
2. 如果一个人拥有多个角色、且不同角色的组织权限的级别不同，怎么处理？
3. 有功能权限就一定可以处理业务记录吗？

三、更复杂应用：房产销售中的业务组织+项目组织

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

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