5.5 KiB
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-step4-confirm-continuity-sms | 确认执行页 2 问题：①车辆接续只显示第一段车/师傅 ②「不发送短信」口径澄清（仅控制确认后行程短信） | admin | wx(GIT) | 前端缺陷 | not_required | not_required | implemented | mmg | 6709c157 | 前端已实现：①Step4Confirm 新增 assignments prop（父层 confirmationAssignments），多段时遍历渲染每段「服务日期段+车辆+师傅」（confirmationSegments+segmentDateLabel，逐日 serviceDates 优先回退 startDate~endDate），单段/无接续回退单数 prop 旧行为不破；AssignModal 传 :assignments。②「不发送短信」提示改「仅不发送确认后的行程短信，派单通知短信仍会发送」。step4-confirm.spec 补 3 回归用例 5/5 过 + checkpoint 精确文件集全过。 | 2026-08-10 | dev-v3 | 2026-08-10T10:20:00+08:00 |
确认执行页 2 问题：车辆接续只显示第一段 + 「不发送短信」口径澄清
前端缺陷，后端能力已具备、无需改后端。待前端修复。
场景（车辆接续，订单 26-6436 周梦洁，order_id=2086270156475936769）
一个车辆槽位在多天内由不同车辆/司机接续服务：
- 8/23：蒙A-E2E01 道尔吉（driver_id=2065272150012444674，vehicle_id=2085284111341023234）
- 8/24~8/25：蒙A-E2E99 王信（driver_id=2067084362829979650，vehicle_id=2085539421276286978）
问题①：确认执行页「车·师傅」只显示第一段
现象：「车·师傅」只显示 蒙A-E2E01/道尔吉（第一段），没显示王信（第二段）；但「行程短信」行写「全部 2 个执行段·必选」（系统知道有 2 段）。
定位（前端）：Step4Confirm.vue 的 vehicle/driver 是单数 prop，父组件 AssignModal.vue 传入 selVehicleObj/selDriverObj（useVehicleDriverPicker 的当前活动槽位选中快照），模板只用 vehicle?.plate/driver?.name 渲染 1 组。逐日车费同源：dailyVehicleFees ref 由 applyVehicleFeeDraft(assignment.dailyVehicleFees) 填充，同样只取活动槽位单段 assignment 的逐日费用——26-6436 只显示 8/23 ¥1000，缺 8/24-25 王信段（¥1000×2），最终总车费只 ¥1000。
后端数据完整（已核实，无需后端改动）：
GET /admin/fleet/board/orders/2086270156475936769的activeAssignments（List<CurrentAssignmentVO>）返回全部有效派车组，每组含 vehiclePlate/vehicleModel/vehicleSeats/driverName/driverPhone（BoardOrderDetailVO 字段已核实）；dailyVehiclePlan正确返回全部 2 车 2 司机（8/23 蒙A-E2E01/道尔吉 + 8/24-25 蒙A-E2E99/王信）。
期望：确认执行页遍历全部执行段（confirmationAssignments/activeAssignments）展示多段「车辆+师傅」以及各段逐日车费与合计（后端每段均返回 dailyVehicleFees 全部服务日快照 + vehicleFeeTotal），车务能核对完整执行信息与完整车费。
问题②：选「不发送短信」确认后司机仍收到短信——口径澄清
定位（前后端逻辑均正确，非缺陷，建议前端补提示文案）：
| 事实 | 证据 |
|---|---|
| 前端确认时实传 sendItinerarySms | 8/10 09:09 最终确认（王信 8/24-25 转 assigned）落库 fleet_assignment.itinerary_sms_decision=0；8/9 15:10 起历次确认均为 0 —— 前端传值正确 |
| 后端拦截正确 | decision=0 的确认均未创建 ITINERARY_SMS outbox 事件；全订单仅 1 条 ITINERARY_SMS 事件（event_id=2086286779542855682，8/9 11:01:44 创建、12:43 处理成功）对应 8/9 11:01 首次确认（decision=1，当时选择了发送短信） |
| 用户「仍收到短信」的真实来源 | ① 派单通知短信 FLEET_DISPATCH_CREATED（模板 SMS_510265061，与行程短信同模板）：由派单/改派 HOLD_NOTIFICATION 触发，派单时必发，不受 sendItinerarySms 控制——8/10 09:09:09 王信、09:22:39 道尔吉均在「不发送短信」确认（09:09:27）前后收到；② 8/9 11:01 首次确认（选择了发送短信）已发出的行程短信（12:32 发送），后取消改派无法撤回 |
结论：「不发送短信」只控制确认后创建的行程短信事件（FLEET_ITINERARY_READY），不控制派单通知短信（FLEET_DISPATCH_CREATED，派单时必发）。验收项「选不发送短信确认后不创建/不发送行程短信事件」在现行代码与 DB 事实下已成立。
建议前端：确认执行页选择「不发送短信」时提示「仅不发送确认后的行程短信，派单通知短信仍会发送」，避免车务误解。
变更接口
- 无后端接口变化。
验证证据
- DB 实证（TEST hl_fleet_service）：
fleet_assignment全史 16 行，itinerary_sms_decision 仅首次确认=1，其余全部=0；fleet_assignment_insurance_outbox全史仅 1 条 ITINERARY_SMS（首次确认创建，SUCCESS）。 - DB 实证（TEST hl_user_service）：
notification_send_log仅 1 条 FLEET_ITINERARY_READY（8/9 12:32 发王信 185****2756，status=0）；8/10 09:09/09:22 两条为 FLEET_DISPATCH_CREATED（派单短信）。 - 源码核实：
AssignmentService.confirmRequirement/confirm均if (sendItinerarySms)才writeItinerarySms；BoardOrderDetailVO.activeAssignments返回全部执行段。