Expensify/App中发票类型显示逻辑的缺陷分析与修复

问题背景

在Expensify/App的搜索功能中，用户可以通过筛选器选择不同类型的报告，包括费用、聊天、发票等。然而，系统存在一个逻辑缺陷：即使用户账户没有发票功能权限，发票类型仍然会出现在筛选选项中。当用户选择该选项并尝试发送发票时，系统会错误地跳转到"not here"页面。

技术分析

该问题源于搜索功能重构后对类型筛选条件的处理不完善。在重构前的版本中，系统会通过以下条件判断是否显示发票类型：

1. 检查用户是否有发送发票的权限
2. 验证用户是否有包含发票的报告

重构后的代码移除了这些验证逻辑，导致所有用户都能看到发票选项，无论其是否具备相关权限。这种权限控制缺失属于典型的前端验证不完整问题。

解决方案

修复方案主要包含两个关键点：

1. 条件过滤：在渲染类型选项时，重新引入权限验证逻辑。只有当用户同时满足以下条件时才显示发票选项：

   • 在所属工作区拥有发送发票的权限
   • 账户中存在发票类型的报告

2. 代码实现：在SearchFiltersBar组件中添加过滤逻辑，动态调整可见的类型选项。具体实现方式有两种：

   • 在渲染时过滤完整类型列表
   • 在构建类型选项时就排除不符合条件的项目

技术细节

修复代码的核心逻辑是：

let visibleTypeOptions = typeOptions;
if (!canSendInvoice(allPolicies, session?.email) && !hasInvoiceReports()) {
    visibleTypeOptions = visibleTypeOptions.filter(typeOption => typeOption.value !== CONST.SEARCH.DATA_TYPES.INVOICE)
}

这种实现方式保证了：

• 向后兼容性：不影响其他已有功能
• 可维护性：逻辑清晰易于理解
• 性能：仅在必要时进行过滤计算

经验总结

这个案例提醒我们在进行功能重构时需要注意：

1. 确保新实现包含所有原始逻辑
2. 权限验证应该贯穿整个功能流程
3. 对于关键业务功能，应该保留完整的测试用例

通过这次修复，Expensify/App的搜索功能恢复了正确的权限控制，确保了用户体验的一致性和系统功能的完整性。这也为类似的前端权限控制问题提供了参考解决方案。