文件
hl-api-changelog/changelogs-v2/2026-08/10_frontend_多槽位原子提交后登记司机已确认按钮恒灰-前端缺陷-管理后台.md
T
Mimingguang 87ed9d0a3f
changelog-filename-gate / validate (push) Failing after 2s
chore(changelog): 全量清理 implemented 存量——81 条复核翻 verified + 1 条改判 not_required + #5827 补登 frontend_ref
处置明细(mmg 2026-09-18):
- 68 条机械核验通过批量翻 verified:frontend_ref 均可达且为 v2.1 祖先、
  交付文件 HEAD 均在、关联 spec 批量 58 文件 891 例全绿。
- 11 条带演进史的例外逐条核后翻 verified:3 条交付自删文件(06_5610/
  07_5655/11_5810,删除即交付内容且终态保持);8 条被后续 changelog 预期
  演进(10_5784→#5810、07_5664/08_5592→#5827、07_5665→去槽位化 U1、
  01_5380/05_5356/06_5567/06_5581→settlement 族A扁平化与 mock 清理),
  status_note 均如实记录演进链。
- 05_5552 改判 not_required:frontend_ref 自述前端无需改动,grep 实证
  vehicleFeeAmount.js 直接读后端 calendarPrice/calendarPriceMissing。
- 11_5827 frontend_ref 原空,经核交付即 753503c8(向导 4 步改 3 步提交
  即派定),补登全哈希 753503c87cc635e5646b4368a8ed506746c79cf1。
另:保险域 2 条相邻条目(05_5530/06_5593)同标准复核翻 verified。
2026-07 历史月 45 条按规则不回扫,保持原状。
2026-09-18 15:56:52 +08:00

5.3 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(GIT) 前端缺陷 not_required not_required verified mmg f02dc8e3 2026-09-18 前端已实现:useAssignFlow batch 分支 emit('submitted-keep-open') 后 await nextTick,从响应逐槽 assignments 按当前预览 tab(新增 activePreviewKey 入参=key=fleetItemIndex)取该槽位 assignment.id 落 activeAssignmentId(缺省回退首槽)并置 stage/finalized;AssignModal 传 activePreviewKey: activeMessagePreviewKey。useAssignFlow.spec 37/37(含多槽位按 tab 落 id 用例)、AssignModal 关联 65/65、checkpoint 全过。tab 切换逐段登记由 confirmHold 恢复态槽位选择联动,整组确认读后端 driverConfirmationSummary.allDriverConfirmed。[mmg 2026-09-18 批量复核翻 verified] ref f02dc8e3 可达且为 v2.1 祖先;交付文件 HEAD 均在;关联 spec 批量 891 例全绿。 2026-09-18 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 个槽位 → 「下一步」原子提交 → 弹窗保持开启停在「待确认」→ 观察右下角「登记司机已确认」按钮灰掉不可点。

关联 / 联系人

链接

  • 前置前端改动: 4c81471c(派单待确认页点「下一步」窗口保持开启,本缺陷由其暴露)
  • 相关 changelog: changelogs-v2/2026-08/09_frontend_派单待确认页点下一步窗口关闭应保持开启-前端缺陷-管理后台.md

联系人

  • 后端负责人: @wx
  • 前端负责人: @mmg