88 行
5.2 KiB
Markdown
88 行
5.2 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "frontend-fleet-batch-register-driver-confirm-disabled"
|
||
title: "多槽位原子提交后停留在「待确认」页，「登记司机已确认」按钮恒灰不可点"
|
||
consumer: "admin"
|
||
author: "wx(GIT)"
|
||
change_type: "前端缺陷"
|
||
backend_status: "not_required"
|
||
gateway_status: "not_required"
|
||
frontend_status: "implemented"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "f02dc8e3"
|
||
target_release: ""
|
||
verified_at: "2026-08-10"
|
||
status_note: "前端已实现：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。"
|
||
updated_at: "2026-08-10"
|
||
base: "dev-v3"
|
||
generated: "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 后）：
|
||
|
||
```js
|
||
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：
|
||
|
||
```js
|
||
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](https://git.1814.love:8443/wx/hl-ui/commit/4c81471c)（派单待确认页点「下一步」窗口保持开启，本缺陷由其暴露）
|
||
- **相关 changelog**: `changelogs-v2/2026-08/09_frontend_派单待确认页点下一步窗口关闭应保持开启-前端缺陷-管理后台.md`
|
||
|
||
### 联系人
|
||
|
||
- **后端负责人**: @wx
|
||
- **前端负责人**: @mmg
|