hl-api-changelog/changelogs-v2/2026-09/29_frontend_团期详情用车需求确认弹窗点确认不发请求-前端缺陷-管理后台.md

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

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
hl-changelog/v2	frontend	团期详情「用车」块按户确认接送机弹窗，点「确认」关窗不发请求：弹窗键名写错（onPositive vs onPositiveClick）	admin	wx(GIT)	前端缺陷	not_required	not_required	implemented	mmg	01acf7734a778e6cb05b8ace8503f73e04f87ac7	v2.1	2026-09-29	前端 2026-09-29 已修复：3 处 onPositive 全改 onPositiveClick(VehicleHouseholdsSection 按户批量/单户接送机、RequirementTab 整团确认),两 spec 的 dialog mock 改只调 onPositiveClick(键名回退即红),49 例全绿,全局 grep 零残留	2026-09-29	dev-v3

团期详情用车需求确认弹窗，点确认关窗不发请求

服务: hl-order-service-v3（后端无改动，接口正常）
页面: 管理后台 → 团期订单 → 进入团期（团期详情）→「查看需求」Tab →「用车 · 子订单用车需求记录」块
接口: POST /v3/admin/order/{orderId}/vehicle-requirement/dispatch?kind=TRANSFER
日期: 2026-09-29
影响范围: 前端。同一写法共 3 处：单户确认接送机（wx 实测复现）、按户批量确认、整团确认（后两处为同一代码形态的静态推断，未实点）。

---

一、现象

1. 进入团期详情，切到「查看需求」Tab。
2. 在「用车 · 子订单用车需求记录」块找某户的接送机行，点「确认」按钮。
3. 弹出「确认接送机需求 / 确认放行「[客户名]」的接送机需求至车务处理?」。
4. 点弹窗中的「确认」按钮。
5. 弹窗关闭，但 Network 标签页无任何新请求。

实测团期：2100856430494973953「王晓测试团期产品·第3期 10月8日出发团」，客户王有亿的接送机行（requirementId=2102202475291549698，状态待审核 PENDING_REVIEW）。

---

二、根因

hl-ui（origin/v2.1 @ 4b800a29）src/views/order-v2/batch/detail/components/ 下两个组件的确认弹窗用了错误的回调键名 onPositive。

naive-ui（hl-ui 装的 2.44.1）useDialog().warning({...}) 只认 onPositiveClick 作为"确认"按钮回调；写成 onPositive 时被静默忽略。来自 node_modules/naive-ui/es/dialog/src/DialogEnvironment.mjs 第 62-73 行：

handlePositiveClick() 只调 props.onPositiveClick，若不存在直接 hide() 关窗

三处错误的键名：

1. VehicleHouseholdsSection.vue:387 —— 单户接送机确认 confirmTransfer 函数内弹窗（本次复现的那处；引入提交 91d476c9，2026-09-22）
2. VehicleHouseholdsSection.vue:334 —— 按户批量确认 openBatchConfirm 函数内弹窗（同一写法，静态推断同样不发请求，未实点）
3. RequirementTab.vue:588 —— 整团确认弹窗（onPositive: () => doConfirm()；引入提交 96ef0c07，2026-09-08；静态推断，未实点）

全 hl-ui 有 76 个文件用的是 onPositiveClick；写成 onPositive: 的只有上面 2 个文件 3 处。

---

三、后端验证（均正常）

测试服对后端接口直接探测（2026-09-29）：

请求	结果
POST /v3/admin/order/1/vehicle-requirement/dispatch?kind=TRANSFER（不存在订单）	HTTP 200，code=581007「订单不存在」，说明路由与端点都可用

探测用的是不存在的订单，对任何订单零写入。王有亿这行在 GET /v3/admin/order/group-batch/2100856430494973953/requirement/vehicle-households 里为 orderId=2100856430239121409、requirementId=2102202475291549698、kind=TRANSFER、status=PENDING_REVIEW，满足按钮显示与可确认的前置条件。

后端契约不变，无改动需求。

---

四、修复方案

VehicleHouseholdsSection.vue

第 334 行：

// 当前（错）：
onPositive: () => doBatchConfirm(),
// 改为（正）：
onPositiveClick: () => doBatchConfirm(),

第 387 行：

// 当前（错）：
onPositive: () => doConfirmTransfer(household, req),
// 改为（正）：
onPositiveClick: () => doConfirmTransfer(household, req),

RequirementTab.vue

第 588 行附近（整团确认弹窗）同样改键名为 onPositiveClick:。

---

五、单测同步修正

两个规格文件的 dialog.warning mock 中，当前直接调用 opts.onPositive()，验不出键名错误。需同步修正：

• __tests__/VehicleHouseholdsSection.spec.js —— 第 257、288、346、395、441 行的 mock implementation
• __tests__/RequirementTab.spec.js —— 第 169、204、423、447 行直接调 onPositive()（第 144、167 行是用例名与注释里的字样，一并改）

修正方法：确保 mock 只调 onPositiveClick，不调 onPositive。这样键名一旦写错，用例会红。

---

六、业务边界

• 确认按钮调的是 POST /v3/admin/order/{orderId}/vehicle-requirement/dispatch?kind=TRANSFER。
• 「确认」按钮只在 kind=TRANSFER 且 status=PENDING_REVIEW 的行上出现（VehicleHouseholdsSection.vue:291 canConfirmReq）。
• 修复后，按钮点击会正常发出请求，后端返回成功后列表刷新并同步父级预检状态。
• 按户批量确认（同一块内）与整团确认（Tab 顶部）是同一写法，一并修；此修复只涉及弹窗回调键名，无新增端点或参数。

---

七、验收

1. 在测试团期 2100856430494973953 点王有亿接送机行的「确认」按钮。
2. 弹窗确认后，Network 显示新请求 POST /v3/admin/order/2100856430239121409/vehicle-requirement/dispatch?kind=TRANSFER。
3. 接口返回成功（HTTP 200），列表自动刷新，该行状态更新为接口返回值。
4. 批量确认、整团确认各点一遍，同样看到请求发出。
5. 两个 spec 文件改 mock 为 onPositiveClick 后全绿；临时把源码改回 onPositive 时相关用例变红。