From c98b11fa442d1d79fc07a2ff23da7efe36de2546 Mon Sep 17 00:00:00 2001 From: Mimingguang <498526323@qq.com> Date: Thu, 1 Oct 2026 00:09:34 +0800 Subject: [PATCH] =?UTF-8?q?chore(changelog):=20#8562=20=E5=9B=9E=E5=86=99?= =?UTF-8?q?=20implemented(hl-admin=20e3f3d552)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...用车区分从未提交与已被打回待重提-修改接口-管理后台.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/changelogs-v2/2026-09/30_8562_团期逐户用车区分从未提交与已被打回待重提-修改接口-管理后台.md b/changelogs-v2/2026-09/30_8562_团期逐户用车区分从未提交与已被打回待重提-修改接口-管理后台.md index d29cc9ab..63a362ce 100644 --- a/changelogs-v2/2026-09/30_8562_团期逐户用车区分从未提交与已被打回待重提-修改接口-管理后台.md +++ b/changelogs-v2/2026-09/30_8562_团期逐户用车区分从未提交与已被打回待重提-修改接口-管理后台.md @@ -7,12 +7,12 @@ author: "wx(GIT)" change_type: "修改接口" backend_status: "deployed" gateway_status: "not_required" -frontend_status: "pending" -frontend_owner: "" -frontend_ref: "" -target_release: "" -verified_at: "" -status_note: "GET /v3/admin/order/group-batch/{groupBatchId}/requirement/vehicle-households 的 households[] 新增三个字段：submitState（户级提交态，恒非 null，三取值 NEVER_SUBMITTED 从未提交 / SUBMITTED 已提交 / REJECTED_PENDING_RESUBMIT 已被打回待重提）、submitStateName（其中文名，后端下发）、rejectedRequirements（该户当前处于打回待重提的类别明细，恒非 null，无打回时为空数组，按展示序 TRAVEL 在前）。背景：用车的打回是「原地置 REJECTED_* + is_active=0」，被打回的户因此没有任何活跃需求行，与从未提交的户在 status 上完全同形（都是 null），车务照 status 催办会把「已交过、只是被驳回」和「压根没动过」混成一堆。四条必须照做的限定：(1) status 字段的取值规则一字未改、仍只由活跃行决定，判「有没有提交过」一律读 submitState，不要读 status 是否为 null；(2) requirements 列表内容零变化，被打回的行仍然不在里面，打回信息只在 rejectedRequirements；(3) rejectedRequirements 的元素刻意不与需求行同构（只有类别/打回状态/打回意见/打回时刻/版本号，没有车队明细、服务日期、座位数），不可当作需求行渲染，否则同一户会出现与活跃行自相矛盾的一条；(4) householdCount 口径再放宽一项，不再恒等于 needs_vehicle=true 的户数——一个 needs_vehicle 为假、没有活跃行、但有一类被打回的户现在也会进列表，判「这户为什么在列表里」看 submitState，不要拿 needsVehicle 反推。另两个数一字不动：vehicleRowCount（被打回的户贡献 0 行）与 countedHouseholdCount（只认活跃 TRAVEL 行），座位汇总口径不会因为有人被驳回而跳变。submitState 与 requirements 同受 kind 筛选影响：传 kind=TRAVEL 时，一个只有接送机被打回的户读成 NEVER_SUBMITTED；要看全貌就不传 kind（不传 = 两类都返）。已知边界（定案、非缺陷）：TRANSFER 需求被「不再需要接送」失活（#8435）且没有新版时，既无活跃行也非打回，读成 NEVER_SUBMITTED，与从未提交对催办动作的要求一致，故不另立一态。入参、分页、排序、错误码（589500 / 589507 / 809000 / 401）与其余响应字段均未变化。" +frontend_status: "implemented" +frontend_owner: "hl-admin(claude-opus-4-8)" +frontend_ref: "e3f3d55265bf7f017d795e6e049601cee700dbfc" +target_release: "v2.1" +verified_at: "2026-09-30" +status_note: "GET /v3/admin/order/group-batch/{groupBatchId}/requirement/vehicle-households 的 households[] 新增三个字段：submitState（户级提交态，恒非 null，三取值 NEVER_SUBMITTED 从未提交 / SUBMITTED 已提交 / REJECTED_PENDING_RESUBMIT 已被打回待重提）、submitStateName（其中文名，后端下发）、rejectedRequirements（该户当前处于打回待重提的类别明细，恒非 null，无打回时为空数组，按展示序 TRAVEL 在前）。背景：用车的打回是「原地置 REJECTED_* + is_active=0」，被打回的户因此没有任何活跃需求行，与从未提交的户在 status 上完全同形（都是 null），车务照 status 催办会把「已交过、只是被驳回」和「压根没动过」混成一堆。四条必须照做的限定：(1) status 字段的取值规则一字未改、仍只由活跃行决定，判「有没有提交过」一律读 submitState，不要读 status 是否为 null；(2) requirements 列表内容零变化，被打回的行仍然不在里面，打回信息只在 rejectedRequirements；(3) rejectedRequirements 的元素刻意不与需求行同构（只有类别/打回状态/打回意见/打回时刻/版本号，没有车队明细、服务日期、座位数），不可当作需求行渲染，否则同一户会出现与活跃行自相矛盾的一条；(4) householdCount 口径再放宽一项，不再恒等于 needs_vehicle=true 的户数——一个 needs_vehicle 为假、没有活跃行、但有一类被打回的户现在也会进列表，判「这户为什么在列表里」看 submitState，不要拿 needsVehicle 反推。另两个数一字不动：vehicleRowCount（被打回的户贡献 0 行）与 countedHouseholdCount（只认活跃 TRAVEL 行），座位汇总口径不会因为有人被驳回而跳变。submitState 与 requirements 同受 kind 筛选影响：传 kind=TRAVEL 时，一个只有接送机被打回的户读成 NEVER_SUBMITTED；要看全貌就不传 kind（不传 = 两类都返）。已知边界（定案、非缺陷）：TRANSFER 需求被「不再需要接送」失活（#8435）且没有新版时，既无活跃行也非打回，读成 NEVER_SUBMITTED，与从未提交对催办动作的要求一致，故不另立一态。入参、分页、排序、错误码（589500 / 589507 / 809000 / 401）与其余响应字段均未变化。;前端已交付:逐户表车侧判提交/判打回改读 submitState,「已打回」筛选与徽标覆盖车侧打回户,无活跃行户级文案用后端 submitStateName,rejectedRequirements 单独提示行不当需求行渲染,4 例定向测试全绿(hl-admin e3f3d552)" updated_at: "2026-09-30" base: "dev-v3" ---