From 425b4c7e76db40963e7d81e1b21d08d3bc15901f Mon Sep 17 00:00:00 2001 From: Mimingguang <498526323@qq.com> Date: Wed, 23 Sep 2026 09:30:54 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog):=20#8142=20not=5Frequired=20?= =?UTF-8?q?=E8=A1=A5=20mmg=20=E5=A4=8D=E6=A0=B8=E8=AF=81=E6=8D=AE(row-key/?= =?UTF-8?q?=E8=99=9A=E6=8B=9F=E5=BE=85=E6=B4=BE/=E6=9C=AA=E8=AF=BB=20Map?= =?UTF-8?q?=20=E4=B8=89=E5=A4=84=E5=AE=9E=E8=AF=81)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...车与接送机并存时接送机需求整行从派单看板消失-修复-管理后台.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs-v2/2026-09/23_8142_行程用车与接送机并存时接送机需求整行从派单看板消失-修复-管理后台.md b/changelogs-v2/2026-09/23_8142_行程用车与接送机并存时接送机需求整行从派单看板消失-修复-管理后台.md index 41864a59..4434de18 100644 --- a/changelogs-v2/2026-09/23_8142_行程用车与接送机并存时接送机需求整行从派单看板消失-修复-管理后台.md +++ b/changelogs-v2/2026-09/23_8142_行程用车与接送机并存时接送机需求整行从派单看板消失-修复-管理后台.md @@ -12,7 +12,7 @@ frontend_owner: "" frontend_ref: "" target_release: "" verified_at: "" -status_note: "本条不改变 GET /admin/fleet/board/orders 的任何响应字段名、类型或嵌套结构，变的是记录的产出规则：修复前该端点在「一单同时有活跃 TRAVEL 需求与活跃 TRANSFER 需求」时只产出其中一条需求的记录，另一条整行不出现（且出现的那条还可能挂着另一类的 requirementRemark 与派车行）；修复后每条活跃用车需求各出一条记录。gateway_status=not_required：零新增路由，端点既有。frontend_status=not_required：hl-ui（origin/v2.1）的看板列表与卡片视图早已用 requirementId 作 row-key（src/views/fleet/board/utils/boardSummary.js:9-14，resolveBoardRecordKey，注释原文「看板已按当前有效用车需求聚合；列表身份必须锚定 requirementId，历史响应缺失时才回退原记录/订单 ID」），同一订单多条记录不会撞 key，无需前端改动——这是查证结论不是推断，若后续发现有按 orderId 去重的调用点，以那处为准另发订正。backend_status=deployed：hl-fleet-service 与 hl-order-service-v3 均已滚动到测试服 78d0aad3d（分别 2026-09-23 07:38:54 / 07:40:25），并在测试服活体上完成改前/改后对跑取证，读数见正文第四节。" +status_note: "本条不改变 GET /admin/fleet/board/orders 的任何响应字段名、类型或嵌套结构，变的是记录的产出规则：修复前该端点在「一单同时有活跃 TRAVEL 需求与活跃 TRANSFER 需求」时只产出其中一条需求的记录，另一条整行不出现（且出现的那条还可能挂着另一类的 requirementRemark 与派车行）；修复后每条活跃用车需求各出一条记录。gateway_status=not_required：零新增路由，端点既有。frontend_status=not_required：hl-ui（origin/v2.1）的看板列表与卡片视图早已用 requirementId 作 row-key（src/views/fleet/board/utils/boardSummary.js:9-14，resolveBoardRecordKey，注释原文「看板已按当前有效用车需求聚合；列表身份必须锚定 requirementId，历史响应缺失时才回退原记录/订单 ID」），同一订单多条记录不会撞 key，无需前端改动——这是查证结论不是推断，若后续发现有按 orderId 去重的调用点，以那处为准另发订正。backend_status=deployed：hl-fleet-service 与 hl-order-service-v3 均已滚动到测试服 78d0aad3d（分别 2026-09-23 07:38:54 / 07:40:25），并在测试服活体上完成改前/改后对跑取证，读数见正文第四节。 mmg 2026-09-23 复核: grep 实证 resolveBoardRecordKey 锚定 requirementId(boardSummary.js:9-14)多单不撞 key;virtualPending 为既有字段,index.vue/display.js/AssignModal 均已消费;域内唯一按 orderId 建的 Map 是未读数查找表(unreadByOrderId),多单同值无冲突——not_required 成立。" updated_at: "2026-09-23" base: "dev-v3" ---