changelog-filename-gate / validate (push) Failing after 1s

详情

docs(changelog): 多槽位原子提交后「登记司机已确认」按钮恒灰（前端缺陷）

26-9313 两槽位原子提交后弹窗保持开启停在待确认页，登记按钮 disabled。
后端已实测排除：batch 响应逐槽返回 assignment.id、看板列表行 assignmentId
非空、DB 两行 holding 身份完整。断点在前端 batch 分支不设 activeAssignmentId，
且依赖父层刷新+重开 watch 的恢复链在多槽位场景没走通。附建议修法与临时绕过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-10 12:12:28 +08:00

4.4 KiB

原始文件 Blame 文件历史

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base, generated

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base	generated
hl-changelog/v2	frontend-fleet-batch-register-driver-confirm-disabled	多槽位原子提交后停留在「待确认」页，「登记司机已确认」按钮恒灰不可点	admin	wx	前端缺陷	not_required	not_required	pending	mmg			2026-08-10	后端已实测排除：batch 提交响应逐槽返回 assignment.id，看板列表行 assignmentId 非空，数据齐备；断点在前端 batch 分支不设 activeAssignmentId + 依赖父层重开 watch 恢复。	2026-08-10	dev-v3	2026-08-10T12:20:00+08:00

多槽位原子提交后停留在「待确认」页，「登记司机已确认」按钮恒灰不可点

前端交互缺陷，待前端修复。是 frontend-fleet-assign-modal-close-on-next（4c81471c 改为不关窗）之后暴露出来的连带缺口。

现象（TEST 实测，订单 26-9313 孙晓东，2 个车辆槽位）

派单流程勾选 2 个车辆槽位 → 点「下一步」原子提交 → toast「已原子提交 2 个车辆槽位，等待司机确认」，弹窗按 4c81471c 的新行为保持开启、停在第 3 步「待确认」页 → 右下角「登记司机已确认」按钮灰掉点不动，流程走不下去。

后端已排查，数据齐备（非后端问题）

检查项	实测结果
`POST /admin/fleet/assignments/batch` 响应	`BatchAssignmentWriteRespVO.assignments[]` 逐槽返回 `assignment`（复用单派 `AssignmentWriteRespVO`），含 `id`
`GET /admin/fleet/board/orders`（列表行）	`assignmentId = 2086270154022285313`（非空）
`GET /admin/fleet/board/orders/{orderId}`（详情）	顶层无 `assignmentId` 字段（本来就不返回），派单身份走 `currentAssignment.id = 2086270154022285313`；`activeAssignments[]` 两段齐全
DB `fleet_assignment`	两行均 `assignment_status=holding`、`hold_mode=1`，身份完整

定位（前端）

useAssignFlow.js 待确认链路 batch 分支（4c81471c 后）：

if (submission.type === 'batch') {
  message.success(`已原子提交 ${selectedSlots.value.length} 个车辆槽位，等待司机确认`)
  emit('submitted-keep-open')
  return          // ← 全程不设 activeAssignmentId
}

单槽路径走的是 const assignmentId = result?.id ?? result?.assignmentId → activeAssignmentId.value = String(assignmentId)，所以单槽正常。

而 Step3DriverConfirm.vue 的按钮是 :disabled="!assignmentId || uploadingCount > 0"，assignment-id 直接绑 activeAssignmentId。batch 路径下它为空 → 按钮恒灰。

原设计指望父层 onSubmittedKeepOpen → refreshBoardAfterMutation → assignMode.value = 'confirmHold' 触发 AssignModal 重开 watch 走 restoreFlowState() 恢复 assignmentId。实测按钮仍灰，说明这条恢复链在多槽位场景没走通（可能 mode 赋同值 watch 未触发，或恢复时机晚于渲染）——依赖「刷新详情 + 重开 watch」这条长链恢复本身就脆。

建议修法（最短路径）

batch 提交成功后，直接从响应里取当前预览 tab（司机）对应槽位的 id 落到 activeAssignmentId，不再依赖重开 watch：

const items = result?.assignments || []
const current = items.find((it) => it.fleetItemIndex === activeFleetItemIndex) || items[0]
const id = current?.assignment?.id
if (id) activeAssignmentId.value = String(id)

多槽位下第 3 步本身是按司机分 tab 的（截图里「阿木古愣·蒙A-E5555」「巴雅尔·蒙A-S6666」），切 tab 时同步把 activeAssignmentId 换成该 tab 槽位的 id，即可逐段登记司机确认。整组是否都确认了，读后端 driverConfirmationSummary.allDriverConfirmed（多执行段只信服务端守恒汇总，别在前端推导）。

临时绕过（给车务）

关掉派单弹窗，回派单看板重新点开该订单进入确认流程——此时恢复态从看板列表行取 assignmentId（非空），「登记司机已确认」按钮可正常点击。

复现路径

派单看板 → 选一个 2 槽位需求的订单（如 26-9313）→ 排车勾 2 个槽位 → 「下一步」原子提交 → 弹窗保持开启停在「待确认」→ 观察右下角「登记司机已确认」按钮灰掉不可点。

4.4 KiB 原始文件 Blame 文件历史 Unescape Escape