3.7 KiB
3.7 KiB
设计：取消报销资产事前批准强制
设计边界
本轮是对 B1 产品口径的最小纠偏，不新增 schema、feature flag 或审批机制。生产继续运行 0f9f403，新候选只改变 assets 明细的保存/提交条件、前端呈现、seed description 与事实源。
服务端兼容合同
asset_prior_approval_basis 保持 nullable，API 的 assetPriorApprovalBasis?: string | null 保持兼容：
| 场景 | 目标行为 |
|---|---|
| 新建 assets，字段缺失/空白 | 保存 null，允许创建 |
| 编辑 assets，字段 omitted、现值为 null | 保持 null，允许编辑，不发生 null .trim() |
| 编辑 assets，字段 omitted、现值有值 | 保留现有值，避免隐藏 UI 后静默清空 |
| 编辑 assets，字段显式 null/空白 | 清空为 null |
| assets 切换为非 assets | 清空为 null |
| 提交 assets 且字段为空 | 不阻断，继续执行金额、票据和 workflow 门禁 |
创建/编辑仍查询费用类型以验证 enabled/category；category 只用于切换到非 assets 时清理兼容字段，不再决定必填。
删除创建/编辑必填分支时，原本被校验守卫保护的 .trim() 必须同时改为安全归一化：
body.assetPriorApprovalBasis?.trim() || null
targetApprovalBasis?.trim() || null
不允许用非空断言或默认虚构文本代替 null 兼容。
前端数据流
- PC
ReimbursementItemEditor的表单模型移除assetPriorApprovalBasis，不渲染输入、不参与 disabled、不进入onSave。 - PC 详情保存 payload 不再写该字段，编辑初始值也不再从详情 DTO 映射。
- 移动端
ItemFormState、新增/编辑初始化和 mutation payload 同步移除该字段。 - PC 表格与移动卡片移除批准依据展示。API DTO 类型保留，避免对旧服务端/客户端契约做无收益破坏。
主数据说明
seed 继续通过 upsert 更新启用类型 description，不触碰 account_code_default。推荐文案：
- 设备采购：
通用设备采购；请在明细说明中写明物品名称、实际使用人或责任人、存放位置，便于资产登记。 - 家具采购：
办公家具采购；请在明细说明中写明物品名称、实际使用人或责任人、存放位置，便于资产登记。 - 办公电子设备：
单条明细金额达到 2,000 元的办公电子设备通常选择本类型；请在明细说明中写明物品名称、实际使用人或责任人、存放位置，便于资产登记。该门槛不等同于会计固定资产确认标准。
发布与回滚
- 无 migration；init 仍可运行既有 migration status + seed 流程，必须确认 pending=none、seed 退出码 0。
- 部署后核对三个 description、B2 仍为 global on、
/ready和 bundle marker 为新候选。 - 公网用合成 assets 草稿验证 PC/移动保存和提交，不使用 0017 做 smoke。
- 异常时回滚应用到本轮发布前候选
0f9f403；数据库兼容列和已存在值不需要补偿。回滚后旧候选会恢复强制，因此 0017 在纠偏验收完成前始终不得退回。
风险控制
- 最大兼容风险是隐藏输入后编辑请求携带 null，误清历史值；通过前端 payload 断言和服务端 omitted-field 测试锁定。
- 最大运行时风险是删除必填校验后暴露下游
.trim()的 null/undefined 假设；创建 omitted、编辑 null omitted 和编辑有值 omitted 三条路由测试必须同时覆盖。 - 最大文案风险是四处 2,000 元提示只改一半；E2E 同时覆盖 PC/移动编辑态和展示态。
- seed 失败会造成代码已取消强制但费用类型仍宣称要批准；部署验收必须同时核应用行为和三条主数据文案。