RuoYi-Vue-Pro项目CRM模块下属合同查询问题分析与修复

问题背景

在RuoYi-Vue-Pro项目的CRM模块中，存在一个关于下属合同查询的功能缺陷。当管理员用户尝试查看下属创建的合同时，系统无法正确返回查询结果。这个问题影响了CRM模块中所有涉及查看下属数据的相关功能。

问题分析

通过分析系统执行的SQL查询语句，我们可以清晰地看到问题的根源：

SELECT COUNT(*) AS total
FROM crm_contract t
INNER JOIN crm_permission t1
ON t1.biz_type = 5
AND t1.biz_id = t.id
AND t1.user_id = 130
AND t1.deleted = 0
WHERE t.deleted = 0 AND (t.owner_user_id IN (131, 132) AND t.owner_user_id IS NOT NULL)

在这个查询中，存在两个关键条件：

1. 通过INNER JOIN连接权限表，要求权限表中的user_id必须等于当前管理员用户ID(130)
2. 在WHERE子句中，又要求合同的所有者ID(owner_user_id)必须是下属用户ID(131或132)

这两个条件实际上是相互矛盾的，因为合同的所有者不可能是管理员自己(130)同时又属于下属用户(131或132)。这种逻辑冲突导致了查询结果为空。

问题影响范围

这个问题不仅影响合同查询功能，还影响了CRM模块中所有使用相同数据权限处理逻辑的功能。具体表现为：

1. 管理员无法查看下属创建的合同
2. 部门主管无法查看部门成员的业务数据
3. 所有基于"查看下属数据"权限的功能都可能受到影响

解决方案

针对这个问题，正确的解决方案应该是：

1. 修改数据权限过滤逻辑，确保管理员可以查看下属的数据
2. 在权限验证部分，应该只检查管理员是否有权限查看数据，而不应该限制数据的所有者
3. 对于下属数据的查询，应该只基于组织结构关系，而不需要额外的权限验证

修复后的查询逻辑应该类似于：

SELECT COUNT(*) AS total
FROM crm_contract t
WHERE t.deleted = 0 
AND t.owner_user_id IN (下属用户ID列表)

技术实现建议

在实现这类数据权限控制时，建议采用以下模式：

1. 对于管理员用户，直接基于组织结构关系查询下属数据
2. 对于普通用户，才需要严格的权限验证
3. 将数据权限控制逻辑抽象为独立的服务组件
4. 实现灵活的数据权限策略，支持不同级别的访问控制

总结

数据权限控制是企业级应用中的常见需求，也是容易出错的复杂功能点。在RuoYi-Vue-Pro项目中发现的这个下属合同查询问题，提醒我们在实现类似功能时需要注意：

1. 权限验证逻辑与业务数据过滤逻辑的分离
2. 不同角色用户的数据访问策略差异
3. 查询条件的逻辑一致性检查
4. 功能影响的全面评估

通过修复这个问题，不仅解决了CRM模块的具体功能缺陷，也为项目中其他类似的数据权限控制场景提供了参考解决方案。