docs(changelog): #7925/#7937/#8023/#8030 前端接入「用房·汇总」建页交付,翻 verified(mmg@9a14ad86)
changelog-filename-gate / validate (push) Failing after 2s
changelog-filename-gate / validate (push) Failing after 2s
这个提交包含在：
Mimingguang
@@ -7,12 +7,12 @@ author: "jw(GIT)"
|
||||
change_type: "修改接口"
|
||||
backend_status: "deployed"
|
||||
gateway_status: "verified"
|
||||
frontend_status: "not_required"
|
||||
frontend_status: "verified"
|
||||
frontend_owner: "mmg"
|
||||
frontend_ref: ""
|
||||
frontend_ref: "9a14ad866b3ef6ac9acb0ca9ab9e9f0fe98f6559"
|
||||
target_release: ""
|
||||
verified_at: ""
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 有一处行为变更 + 三个纯新增出参。行为：dailyRoomBreakdown 每日房间合计此前把「已改成不需要订房」的户和「被打回重改中」的户也算进去，房数虚高；现在只计 needsHotel=true 且状态非打回的户，与整体确认前的缺失预检口径一致。新增出参 hotelNeededOrderCount（需房户数）、hotelSubmittedOrderCount（需房且已提交的户数，即计入合计的户数）、dailyRoomBreakdown[].rooms[].roomCategoryName（房型中文名，字典无此编码时为 null）。既有字段一个没删没改。户范围保持「在团」口径（含已完成的户），与预检刻意不同，见第四节。后端已合并 dev-v3（20465f21e）并部署 TEST，网关实测通过（工单 #7925 AC-2~AC-5）。前端实证（hl-ui v2.1，2026-09-20）：全仓 grep requirement-summary / dailyRoomBreakdown / hotelNeededOrderCount / hotelSubmittedOrderCount 均 0 命中，前端尚未消费该汇总端点，合计口径修正与三个新增出参对现有页面零影响（v3Adapter / useSettlementHotelResources 中同名 roomCategoryName 属订单结算/房务候选另一数据源，与本端点无关）。将来「查看需求」页接入户数与房型中文名属新功能排期，非本件义务，翻 not_required。"
|
||||
verified_at: "2026-09-20"
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 有一处行为变更 + 三个纯新增出参。行为：dailyRoomBreakdown 每日房间合计此前把「已改成不需要订房」的户和「被打回重改中」的户也算进去，房数虚高；现在只计 needsHotel=true 且状态非打回的户，与整体确认前的缺失预检口径一致。新增出参 hotelNeededOrderCount（需房户数）、hotelSubmittedOrderCount（需房且已提交的户数，即计入合计的户数）、dailyRoomBreakdown[].rooms[].roomCategoryName（房型中文名，字典无此编码时为 null）。既有字段一个没删没改。户范围保持「在团」口径（含已完成的户），与预检刻意不同，见第四节。后端已合并 dev-v3（20465f21e）并部署 TEST，网关实测通过（工单 #7925 AC-2~AC-5）。前端实证（hl-ui v2.1，2026-09-20）：全仓 grep requirement-summary / dailyRoomBreakdown / hotelNeededOrderCount / hotelSubmittedOrderCount 均 0 命中，前端尚未消费该汇总端点，合计口径修正与三个新增出参对现有页面零影响（v3Adapter / useSettlementHotelResources 中同名 roomCategoryName 属订单结算/房务候选另一数据源，与本端点无关）。将来「查看需求」页接入户数与房型中文名属新功能排期，非本件义务，翻 not_required。 2026-09-20 前端接入(mmg):「用房 · 汇总」建页随 hl-admin v2.1 交付——requirement-summary 经 getGroupRequirementSummary 接入「查看需求」页 RoomSummarySection:户数条(在团/需订房/已提交)+不一致只提示不扣减+Day N|酒店|房型|所需间数扁平表;stayDate null 按 Day N、hotelName null 显「未知酒店」不隐藏行、roomCategoryName null 回落编码、全天合计直读 rooms[] 禁跨酒店累加、hotelId null 组间数不丢;整团确认/按户打回后自动重拉。定向 Vitest 17/17,checkpoint 全绿。"
|
||||
updated_at: "2026-09-20"
|
||||
base: "dev-v3"
|
||||
---
|
||||
|
||||
@@ -7,12 +7,12 @@ author: "jw(GIT)"
|
||||
change_type: "修改接口"
|
||||
backend_status: "deployed"
|
||||
gateway_status: "verified"
|
||||
frontend_status: "not_required"
|
||||
frontend_status: "verified"
|
||||
frontend_owner: "mmg"
|
||||
frontend_ref: ""
|
||||
frontend_ref: "9a14ad866b3ef6ac9acb0ca9ab9e9f0fe98f6559"
|
||||
target_release: ""
|
||||
verified_at: ""
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 vehicleSeatSummary[] 新增一个出参 vehicleTypeName（车型大类中文名，如 SUV系列），取自车队「车型管理库」fleet_vehicle_type.type_name。既有的 vehicleType 仍是编码（suv/mpv/bus/sedan）、原样返回，没删没改；本次是纯增量，其余字段与入参、路径、错误码均不变。车队不可用或该编码在车型管理库里查不到时 vehicleTypeName 为 null，汇总接口本身照常 200。配套在 hl-fleet-service 新增内部只读端点（服务间调用，前端不可见）。后端已合并 dev-v3（079732ca2）并部署 TEST，网关实测通过（工单 #7937 AC-4/AC-5）。前端实证（hl-ui v2.1，2026-09-20）：vehicleSeatSummary 全仓 grep 0 命中，前端尚未消费该汇总端点；vehicleTypeName 同名命中全在 fleet 司机列表/车辆选择器/趣味项调整等别域既有 API 字段，与本端点无关。纯增量出参对现有页面零影响，将来「查看需求」页接入车型中文名属新功能排期，非本件义务，翻 not_required。"
|
||||
verified_at: "2026-09-20"
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 vehicleSeatSummary[] 新增一个出参 vehicleTypeName（车型大类中文名，如 SUV系列），取自车队「车型管理库」fleet_vehicle_type.type_name。既有的 vehicleType 仍是编码（suv/mpv/bus/sedan）、原样返回，没删没改；本次是纯增量，其余字段与入参、路径、错误码均不变。车队不可用或该编码在车型管理库里查不到时 vehicleTypeName 为 null，汇总接口本身照常 200。配套在 hl-fleet-service 新增内部只读端点（服务间调用，前端不可见）。后端已合并 dev-v3（079732ca2）并部署 TEST，网关实测通过（工单 #7937 AC-4/AC-5）。前端实证（hl-ui v2.1，2026-09-20）：vehicleSeatSummary 全仓 grep 0 命中，前端尚未消费该汇总端点；vehicleTypeName 同名命中全在 fleet 司机列表/车辆选择器/趣味项调整等别域既有 API 字段，与本端点无关。纯增量出参对现有页面零影响，将来「查看需求」页接入车型中文名属新功能排期，非本件义务，翻 not_required。 2026-09-20 前端接入(mmg):「用房 · 汇总」建页随 hl-admin v2.1 交付——requirement-summary 经 getGroupRequirementSummary 接入「查看需求」页 RoomSummarySection:户数条(在团/需订房/已提交)+不一致只提示不扣减+Day N|酒店|房型|所需间数扁平表;stayDate null 按 Day N、hotelName null 显「未知酒店」不隐藏行、roomCategoryName null 回落编码、全天合计直读 rooms[] 禁跨酒店累加、hotelId null 组间数不丢;整团确认/按户打回后自动重拉。定向 Vitest 17/17,checkpoint 全绿。"
|
||||
updated_at: "2026-09-20"
|
||||
base: "dev-v3"
|
||||
---
|
||||
|
||||
@@ -7,12 +7,12 @@ author: "jw(GIT)"
|
||||
change_type: "修改接口"
|
||||
backend_status: "deployed"
|
||||
gateway_status: "verified"
|
||||
frontend_status: "not_required"
|
||||
frontend_status: "verified"
|
||||
frontend_owner: "mmg"
|
||||
frontend_ref: ""
|
||||
frontend_ref: "9a14ad866b3ef6ac9acb0ca9ab9e9f0fe98f6559"
|
||||
target_release: ""
|
||||
verified_at: "2026-09-20"
|
||||
status_note: "后端已合并 dev-v3（df66ec357）并部署 TEST，网关实测 AC-1~AC-8 全通过。一处口径放宽 + 一个纯新增出参 + 一处写侧副作用。口径：全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 dailyRoomBreakdown 与整体确认预检 GET .../requirement/confirm-check，此前都只认订单上的 needs_hotel 标记位，导致「标记说不需要住宿、定制师却已提交完整需求」的户被整户静默丢弃——间数不进汇总（页面用房表空白）、确认时也不放行给房务（需求填了没人配房）；现在计入条件改为「标记为真 或 已提交有效需求」，打回态仍不计。新增出参 hotelFlagMismatchOrderCount 把这种不一致显式暴露。写侧：PUT /v3/admin/order/{id}/hotel-requirement 提交成功后，若该单 needs_hotel 不为真则就地置 1（单向 0→1，同事务，已为真时不写）——该标记原先只在创单时按产品有没有配酒店派生一次、之后全仓无写通道，存量错单改不回来。既有字段一个没删没改，入参与路径不变。 前端实证维持 not_required(mmg 2026-09-20):requirement-summary/dailyRoomBreakdown/hotelNeededOrderCount/hotelFlagMismatchOrderCount 全仓零命中(汇总端点未接入,同 #7925/#7937 结论);confirm-check 已消费(orderV2GroupBatch.js)但出参结构不变,ready/missing 直渲自动受益;hotel-requirement 标记纠正为服务端同事务副作用、响应不变,零感知。"
|
||||
status_note: "后端已合并 dev-v3（df66ec357）并部署 TEST，网关实测 AC-1~AC-8 全通过。一处口径放宽 + 一个纯新增出参 + 一处写侧副作用。口径：全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 dailyRoomBreakdown 与整体确认预检 GET .../requirement/confirm-check，此前都只认订单上的 needs_hotel 标记位，导致「标记说不需要住宿、定制师却已提交完整需求」的户被整户静默丢弃——间数不进汇总（页面用房表空白）、确认时也不放行给房务（需求填了没人配房）；现在计入条件改为「标记为真 或 已提交有效需求」，打回态仍不计。新增出参 hotelFlagMismatchOrderCount 把这种不一致显式暴露。写侧：PUT /v3/admin/order/{id}/hotel-requirement 提交成功后，若该单 needs_hotel 不为真则就地置 1（单向 0→1，同事务，已为真时不写）——该标记原先只在创单时按产品有没有配酒店派生一次、之后全仓无写通道，存量错单改不回来。既有字段一个没删没改，入参与路径不变。 前端实证维持 not_required(mmg 2026-09-20):requirement-summary/dailyRoomBreakdown/hotelNeededOrderCount/hotelFlagMismatchOrderCount 全仓零命中(汇总端点未接入,同 #7925/#7937 结论);confirm-check 已消费(orderV2GroupBatch.js)但出参结构不变,ready/missing 直渲自动受益;hotel-requirement 标记纠正为服务端同事务副作用、响应不变,零感知。 2026-09-20 前端接入(mmg):「用房 · 汇总」建页随 hl-admin v2.1 交付——requirement-summary 经 getGroupRequirementSummary 接入「查看需求」页 RoomSummarySection:户数条(在团/需订房/已提交)+不一致只提示不扣减+Day N|酒店|房型|所需间数扁平表;stayDate null 按 Day N、hotelName null 显「未知酒店」不隐藏行、roomCategoryName null 回落编码、全天合计直读 rooms[] 禁跨酒店累加、hotelId null 组间数不丢;整团确认/按户打回后自动重拉。定向 Vitest 17/17,checkpoint 全绿。"
|
||||
updated_at: "2026-09-20"
|
||||
base: "dev-v3"
|
||||
---
|
||||
|
||||
@@ -7,12 +7,12 @@ author: "jw(GIT)"
|
||||
change_type: "修改接口"
|
||||
backend_status: "deployed"
|
||||
gateway_status: "not_required"
|
||||
frontend_status: "not_required"
|
||||
frontend_status: "verified"
|
||||
frontend_owner: "mmg"
|
||||
frontend_ref: ""
|
||||
frontend_ref: "9a14ad866b3ef6ac9acb0ca9ab9e9f0fe98f6559"
|
||||
target_release: ""
|
||||
verified_at: "2026-09-20"
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 dailyRoomBreakdown 纯增两项：stayDate（该晚住宿日期 = 团期出发日 + dayNumber - 1，团期无出发日时为 null）与 hotels[]（该晚按酒店分组的用房，含 hotelId / hotelName / totalRoomCount / rooms[]）。原有 rooms[]（不分酒店的全天合计）与其余字段一个没动。这样团期「查看需求」页的「用房 · 汇总」表（Day N | 酒店 | 房型 | 所需间数）一个接口就能画完，不必逐户调订单调整快照去拼酒店，也不必等房务建完订房计划——后者在成团前根本没有数据。口径：与 rooms 同一次遍历的两个视角，任一天 Σhotels[].totalRoomCount == Σrooms[].totalRoomCount；每段只取首方案候选（候选是房控择一，累加全部会翻倍）；取不到酒店的段归 hotelId=null 一条且恒排末位，间数不丢；酒店名优先取需求里落库的快照，缺失的按 ID 一次批量补，资源服务不可用时名称为 null、间数照常。 前端实证维持 not_required(mmg 2026-09-20):requirement-summary/dailyRoomBreakdown/stayDate(本端点义)/hotels 全仓零命中(同 #7925/#7937/#8023 第四次实证,汇总端点未接入);「用房·汇总」表属新功能排期,届时 stayDate null 按 Day N 展示、hotelName null 显「未知酒店」不隐藏行、全天合计直读 rooms[] 不跨酒店累加、hotelId 字符串。"
|
||||
status_note: "全团需求汇总 GET /v3/admin/order/group-batch/{groupBatchId}/requirement-summary 的 dailyRoomBreakdown 纯增两项：stayDate（该晚住宿日期 = 团期出发日 + dayNumber - 1，团期无出发日时为 null）与 hotels[]（该晚按酒店分组的用房，含 hotelId / hotelName / totalRoomCount / rooms[]）。原有 rooms[]（不分酒店的全天合计）与其余字段一个没动。这样团期「查看需求」页的「用房 · 汇总」表（Day N | 酒店 | 房型 | 所需间数）一个接口就能画完，不必逐户调订单调整快照去拼酒店，也不必等房务建完订房计划——后者在成团前根本没有数据。口径：与 rooms 同一次遍历的两个视角，任一天 Σhotels[].totalRoomCount == Σrooms[].totalRoomCount；每段只取首方案候选（候选是房控择一，累加全部会翻倍）；取不到酒店的段归 hotelId=null 一条且恒排末位，间数不丢；酒店名优先取需求里落库的快照，缺失的按 ID 一次批量补，资源服务不可用时名称为 null、间数照常。 前端实证维持 not_required(mmg 2026-09-20):requirement-summary/dailyRoomBreakdown/stayDate(本端点义)/hotels 全仓零命中(同 #7925/#7937/#8023 第四次实证,汇总端点未接入);「用房·汇总」表属新功能排期,届时 stayDate null 按 Day N 展示、hotelName null 显「未知酒店」不隐藏行、全天合计直读 rooms[] 不跨酒店累加、hotelId 字符串。 2026-09-20 前端接入(mmg):「用房 · 汇总」建页随 hl-admin v2.1 交付——requirement-summary 经 getGroupRequirementSummary 接入「查看需求」页 RoomSummarySection:户数条(在团/需订房/已提交)+不一致只提示不扣减+Day N|酒店|房型|所需间数扁平表;stayDate null 按 Day N、hotelName null 显「未知酒店」不隐藏行、roomCategoryName null 回落编码、全天合计直读 rooms[] 禁跨酒店累加、hotelId null 组间数不丢;整团确认/按户打回后自动重拉。定向 Vitest 17/17,checkpoint 全绿。"
|
||||
updated_at: "2026-09-20"
|
||||
base: "dev-v3"
|
||||
---
|
||||
|
||||
在新工单中引用
屏蔽一个用户