文件
hl-api-changelog/changelogs-v2/2026-09/23_8221_团级用车分组存量车型归一与SUV下拉回显不匹配-修复-管理后台.md
T
2026-09-23 14:53:47 +08:00

6.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
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 8221 团期正式用车需求: 存量自由文本车型已归一成字典大类 key,原样回传不再撞 809119;前端 SUV 下拉回显需按大类比对 admin jw(GIT) 修复 deployed verified verified mmg c314c8c67ddc61b8a1e4f4373d79e5a731b13272 2026-09-23 接口契约零变化(路径、入参、出参、错误码都没改),变的是库里存量数据:Java 迁移 V20260924_402 把活跃版本上 81 行自由文本车型归一成 suv/mpv/sedan/bus。PR #8236 已合并 dev-v3(f5ffeffe7);TEST order-v3 在 fe752f16c(含本单)上运行,迁移 2026-09-23 12:19:36 执行成功。经真实网关验证:字典 4 个 typeKey 都过了车型校验,minivan 仍报 809119,存量团期原样回传返回 200。gateway_status=verified:零新增路由,在既有端点上做了 round-trip。frontend_status=pending:GroupVehicleRequirementEditModal.vue 判「是否字典值」时拿原值和 typeKey 逐字比,SUV 组回显 suv 对不上 suv2,见正文第三节。 | 2026-09-23 mmg 交付:EditModal 按 vehicleTypeName 匹配字典 typeName 收敛回显,不占位不拦保存 2026-09-23 dev-v3

团期正式用车需求: 存量车型归一 + SUV 下拉回显不匹配

存放目录: 二期(order-v3)→ changelogs-v2/2026-09/

服务: hl-order-service-v3(Flyway Java 迁移) PR: #8236 Issue: #8221 日期: 2026-09-23 影响范围: GET / PUT /v3/admin/order/group-batch/{groupBatchId}/vehicle-requirement 里 groups[].vehicleType 的存量取值


⚠️ 关键变化

  1. 存量团期的 groups[].vehicleType 现在都是规范大类 key(suv / mpv / sedan / bus),不再有 35座大巴、SUV、jiaoche 这类自由文本。 所以打开存量团期的编辑弹窗、不改车型直接保存,不会再撞 809119。
  2. groups[].vehicleTypeName 对这些行现在有值了(如 大巴系列)。以前原值不是 key,取不到中文名,返回 null。
  3. 归一时丢掉的原文(座位数、拼音写法)追加在该组 groups[].remark 里,格式为 原车型:35座大巴;原来有备注的,用 ; 接在后面。
  4. 校验本身没有放宽:字典外的值(如 minivan)照样报 809119,文案不变。

一、变更接口清单

方法 路径 变更性质
GET /v3/admin/order/group-batch/{groupBatchId}/vehicle-requirement 字段结构不变,存量 vehicleType 取值已归一
PUT /v3/admin/order/group-batch/{groupBatchId}/vehicle-requirement 契约不变;存量值原样回传不再被 809119 拒

本条不属于「新增接口 / 修改接口」:请求参数、响应字段、错误码都没有增删改。


二、存量映射表(TEST 实测,活跃版本)

原值 归一后 行数 remark 留底
SUV suv 35 否
35座大巴 bus 15 是
轿车 sedan 13 否
商务车 mpv 10 否
jiaoche sedan 4 是
35zuo daba bus 1 是
7座商务车 mpv 1 是
car sedan 1 是
shangwu mpv 1 是
  • 只改当前活跃版本。历史版本(已失效的需求版本)保持原样,所以查历史时仍可能看到旧的自由文本。
  • 迁移认不出的值会原样保留(TEST 活跃版本里为 0 个),这类值仍会被 809119 拒,需要在下拉里重选。
  • update_time 没有被刷新,这次归一不会显示成一次用户编辑。

三、🔴 前端需要改的一处:SUV 组存完再打开会被判成「非字典值」

现象:GroupVehicleRequirementEditModal.vue 的下拉 value 用的是 GET /admin/fleet/vehicle-types/list 的 typeKey 原值。TEST 上 SUV 这一项的 typeKey 是 suv2。 后端保存时会把提交值归一成大类 key 再落库(suv2 → suv),GET 也原样回显 suv。

vehicleTypeKeys 只有 {suv2, mpv, sedan, bus},于是:

  • vehicleTypeOptionsFor(g)(:306-316)会给这组合成一个 suv(非字典值,请重选) 占位项;
  • vehicleTypeRule(:343-355)把这组判成字典外的值,拦住保存。

⇒ 只要是 SUV 组,每次打开编辑弹窗都得重选一遍。本次归一后,存量 35 行 SUV 都变成了 suv,也会落进这个情况。mpv / sedan / bus 的 typeKey 与大类 key 正好相同,不受影响。

建议改法(选一种):

  • 判断「当前值是否在字典内」时按大类比较:GET 回显的 vehicleTypeName 非空,就说明该值已命中字典大类,可以用它去匹配下拉项的 typeName(TEST 上 suv → SUV系列,与 suv2 的 typeName 相同);
  • 或者在前端维护一张 typeKey → 大类的映射,用来选中回显项。不要写死 suv2:字典是运行期数据,typeKey 是开集,随时可能变。

提交时继续传 typeKey 原值(suv2),后端会自己归一,这一点不变。


四、后端已验证的读数(测试服活体,order-v3 @ fe752f16c)

验证项 读数
迁移执行 flyway_schema_history 版本 20260924.402 success=1,2026-09-23 12:19:36,耗时 11ms
数据终态 活跃版本 83 行全部是规范 key;23 行 remark 带「原车型:」;历史版本 19 行没有动
字典 typeKey 全部能过 suv2 / mpv / sedan / bus 逐个 PUT,都没触发 809119
阴性对照 minivan → 809119 第 ALL 组的车型 minivan 不在车型字典内(不存在或已下线),请从下拉项中选择
存量原样回传 原值为 35座大巴 的团期:GET 回显 bus / 大巴系列,原样 PUT → HTTP 200 / code 200,version 2→3
鉴权 不带 token → 401

五、你需要做的

  • 按第三节改一下 GroupVehicleRequirementEditModal.vue 判断字典值的方式,SUV 组就不用每次重选了。
  • 其他车型不用改:存量值都已经是字典 key,编辑态能正常回显和保存。