Leantime项目中的工单搜索功能兼容性问题分析与解决方案

问题背景

Leantime作为一款开源项目管理工具，在3.4.1版本中对工单搜索功能进行了调整，导致与之前版本存在兼容性问题。这些问题主要体现在两个方面：一是未指定用户ID时获取开放工单的行为变化，二是工单类型筛选条件在特定情况下的失效问题。

核心问题分析

1. 开放工单获取逻辑变更

在3.4.1版本之前，当调用getAllOpenUserTickets方法且未指定用户ID时，系统会返回所有用户的开放工单。而新版本中，这一行为被修改为默认返回当前用户的工单，这导致了与原有API调用预期的不一致。

技术细节：

• 旧版本：用户ID参数可选，未提供时查询所有用户
• 新版本：默认绑定到当前用户，改变了原有行为模式

2. 工单状态筛选条件失效

当使用"not_done"状态筛选且未指定项目ID时，工单类型(type)筛选条件会被忽略。这是由于系统实现中状态筛选逻辑与项目ID的强耦合导致的。

技术实现分析： 系统使用statusListSeed数组定义默认状态类型，包含NEW、INPROGRESS和DONE三种状态类型。但在实际查询中，"not_done"状态的筛选需要依赖项目ID来获取项目的自定义状态配置：

if (array_search('not_done', $statusArray) !== false) {
    if ($searchCriteria['currentProject'] != '') {
        // 获取项目特定状态配置
        $statusLabels = $this->getStateLabels($searchCriteria['currentProject']);
        // 筛选非完成状态
        foreach ($statusLabels as $key => $status) {
            if ($status['statusType'] !== 'DONE') {
                $statusList[] = $key;
            }
        }
    }
}

当项目ID为空时，这段逻辑会被跳过，导致状态筛选失效。

解决方案与改进

开发团队在3.4.3版本中针对第一个问题进行了修复，主要调整了权限控制逻辑：

1. 权限模型重构：

   • 管理员角色：可以查看所有工单
   • 普通用户：只能查看已分配项目中的工单
   • 移除了默认绑定当前用户的逻辑

2. 状态筛选优化建议： 对于未指定项目ID的情况，可以考虑以下改进方案：

   • 使用系统默认状态配置作为回退方案
   • 合并所有相关项目的状态定义
   • 明确文档说明此限制

其他发现的问题

在代码审查中还发现一个潜在的命名不一致问题：

• Tickets.getAll使用userId作为创建者ID参数
• Tickets.getAllOpenUserTickets使用authorId作为相同含义的参数

这种命名不一致可能导致API使用时的混淆，建议统一参数命名规范。

最佳实践建议

1. API调用建议：

   • 明确指定项目ID以获得准确的状态筛选
   • 升级到最新版本并检查权限配置
   • 统一使用userId或authorId参数命名

2. 系统设计考量：

   • 状态管理应考虑项目特定配置与系统默认的平衡
   • API行为变更应通过版本号明确标识
   • 参数命名应保持一致性

总结

Leantime工单搜索功能的这些变更反映了系统在安全性和灵活性之间的权衡。开发者在升级版本时需要特别注意这些行为变化，特别是涉及跨项目查询和状态筛选的场景。理解这些底层实现机制有助于更好地设计API调用方案和预期结果处理逻辑。