2.3 KiB
2.3 KiB
Context
三个后台业务列表都需要展示相同的审批摘要，但各自保留既有退款、充值或换货操作。审批来源和业务处理状态均由后端列表接口返回，前端不请求单条审批详情来填充表格。
Goals / Non-Goals
- Goals:
- 统一展示提交人、审批状态、当前审批人摘要和业务处理状态。
- 正确区分无审批、历史本地审批和企微审批。
- 在不增加逐行请求的前提下支持长摘要完整查看。
- Non-Goals:
- 不创建、修改或撤回审批流程。
- 不增加历史本地审批操作按钮。
- 不以
approval_status推断processing_status，或反向推断。
Decisions
- Decision: 三个列表项模型复用相同名称和语义的审批摘要字段，字段由各自的列表接口直接返回。
- Decision:
approval_source=none时审批状态与当前审批人摘要均显示-；legacy时审批状态固定显示“历史审批”，当前审批人摘要显示-；wecom时直接展示approval_status_name和current_approver_summary。 - Decision: 审批人摘要仅负责展示，使用表格溢出省略与 tooltip 呈现完整文本。
- Decision: 业务处理状态单独读取
processing_status_name，不与审批状态混合或映射。 - Decision: 列表分页和刷新仅调用现有列表 API，禁止为每条记录请求审批详情。
- Alternatives considered: 从单条详情或企微审批 API 批量补齐摘要。未采用，因为会引入 N+1 请求并与列表响应已提供的摘要字段重复。
Risks / Trade-offs
- 后端遗漏摘要字段时信息不可用 -> 统一显示稳定占位，不影响原有列表和业务操作。
- 审批状态名称可能为空 -> 企微来源显示稳定占位，不自行翻译状态码。
- 审批人摘要长度不受控 -> 表格列使用溢出省略和 hover 完整文本。
Migration Plan
- 扩展三个列表项类型以保留审批摘要字段。
- 在三个列表中添加四个展示列并遵循审批来源规则。
- 验证
none、legacy、wecom和处理状态为空的响应。 - 验证刷新、分页未出现逐行审批详情请求。
- 如需回滚，移除列表列与附加类型字段；不涉及数据迁移。
Open Questions
- 无。