42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
## 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
|
||
|
||
1. 扩展三个列表项类型以保留审批摘要字段。
|
||
2. 在三个列表中添加四个展示列并遵循审批来源规则。
|
||
3. 验证 `none`、`legacy`、`wecom` 和处理状态为空的响应。
|
||
4. 验证刷新、分页未出现逐行审批详情请求。
|
||
5. 如需回滚，移除列表列与附加类型字段；不涉及数据迁移。
|
||
|
||
## Open Questions
|
||
|
||
- 无。
|