学海无涯，行者无疆

至此，我们完成了一二三开发平台的数据权限的设计与实现，通过配置，可以灵活的进行多维度的数据权限控制，包括用户、组织机构、用户组以及业务实体属性，控制对象为各个业务实体，无耦合，无侵入。

接下来重点攻坚数据字典。从数据权限规则配置角度，同样我们不使用多选，有需要时转换成多个条件就好了。官方文档中这块说得很少，除了上面常规属性外，增加了两个属性，multiple是否可以多选，multipleLimit，限制多选的最大数量，如下图：但是下拉的数据源哪来的，如何赋值呢？仔细观察上面例子，原先的操作符里放了Gender，看上去像是数据字典类型的编码。然后在API Conditions部分，就放了一个select的示例，啥也没说……

如何获取完整SQL片段此处遇到了一个棘手的问题。我们需要获取到完整的SQL片段，类似这种：((param_value = '10' and param_name like '%用户%' ) or (param_key like '%password%') )。但是MybatisPlus组件的条件构造器QueryWrapper拿不到这种完整的sql片段，而是将sql语句参数和值分开保存的，通过getSqlSegment可以获取到参数化的sql语句，通过getParamNameValuePairs可以获取

在框架开发阶段，我们实现了最简单的单组单条件的转换逻辑。接下来我们一步步来完善，先来进行结构性完善，让转换逻辑可以支持多组多条件的复杂场景。首先是单组两条件，通过循环遍历来实现条件拼接，实际也适用于两个以上条件，需要考虑组内各条件关系是或还是且。转换后规则如下：(param_value = ‘10’ and param_name like ‘% 用户 %’ )符合预期。

至此，已完成了数据权限的整体框架开发，但也只是框架，各环节还有大量的工作需要完善，主要包括以下几点：1. 配置规则时需要增加用户、部门、角色等维度2. 将数据筛选器生成的各种场景下的复杂规则转换为 SQL 片段3. 读取平台运行时变量，替换掉预置的用户、部门等占位符

前面我们对筛选器组件进行了功能探索和技术验证，接下来就开始着手集成工作，融入一二三开发平台，打通前后端，最终让数据权限控制功能落地。整体集成工作比较复杂，我们遵循由易到难的原则，先搭建出完整框架，再具体完善各组成部分。‍。

官方给了全局性的介绍和示例，不过到了具体使用环节，介绍就不是那么清楚明确了，往往是直接放 demo，需要去推测和揣测，然后动手验证。去百度了下，也没找到现成的对该组件的使用说明，得以开荒的方式探索了。‍。

1.API options该接口用于获取触发器和操作符的数据，通过调用该接口，获取可用的触发器和操作符。例如，获取可用的触发器选项，如文本、数字、日期等，以及每个触发器支持的操作符，如等于、不等于、大于、小于等。2.API conditions该接口用于获取字段值（如下拉、级联）的数据。通过调用该接口，可以获取下拉列表、级联选择器等字段值的数据。这些数据可以是静态的，事先定义好的选项列表，也可以是动态的，根据特定条件生成的选项列表。获取字段值的数据可以为筛选器的条件设置提供可选的值。

Everright-filter 是一个通过用户界面轻松生成任何类型的查询语句，使得筛选和过滤数据变得轻而易举。提供多种 UI 界面，赋能不同的业务场景。‍注：官方文档中不少demo地址打不开或报错了。‍。

在前面介绍的若依开发平台和基于MybatisPlus数据权限插件实现的的数据权限控制方案中，都预置了5种数据权限范围。先前分析过这种设计思路存在的一些问题，即对于数据权限的控制维度和实现思路基于部门维度，控制点放在角色上，会造成角色爆炸问题和权限扩大。

本文介绍了MybatisPlus的数据权限插件的机制和使用，并通过一个具体示例补全了关键环节数据权限控制逻辑的实现。与上篇若依开发平台对比，主要区别在于技术实现方式不同。若依开发平台是自行拼接SQL片段，MybatisPlus的数据权限插件是基于拦截器机制，在执行SQL前解析和修改SQL。但对于数据权限的控制维度和实现思路，都是一致的，基于部门维度，控制点放在角色上，因此角色爆炸问题和权限扩大问题，也都存在。

在之前的博客《数据权限的设计与思考》中，我们对软件系统的数据权限进行了全面的梳理。接下来，本文深度剖析主流开源的若依开发平台数据权限是怎么设计与实现的。若依开发平台的数据权限设计比较简易，预置了5种数据范围，具体如下：● 全部数据权限：所有数据，即不做数据权限控制● 部门数据权限：用户自己本部门的数据● 部门及以下数据权限：用户自己本部门及子部门的数据● 自定数据权限：自定义数据权限● 仅本人数据权限：自己的数据从数据范围划分可以看出，平台的数据权限维度主要是部门（部门之外，增加了用户维度的仅

权限控制是一个系统的核心功能，可以分为两类，一类是功能权限，一类是数据权限。数据权限又可以进一步分为行级权限和列级权限。功能权限，是指系统用户能进行哪些操作，通常是菜单和按钮权限，如打开订单菜单，查询订单列表，创建新订单。对于功能权限，有标准化的解决方案，也即RBAC，通过权限项、角色、用户三张主表，以及角色-权限项对应关系表和角色-用户对应关系表两张辅助表，一共5张库表即可实现功能权限的功能，系统管理员通过系统界面即可实现灵活的权限分配和维护。