wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
文件
10b46812d23a51304c00ee1537254b4a07c7265c
hl-api-changelog/changelogs-v2/2026-09/23_frontend_团期详情页用车用房面板3项前端待办-前端缺陷-管理后台.md
T
Mimingguang ebb36b140f
changelog-filename-gate / validate (push) Failing after 1s
详情
changelog: 23_frontend 用车用房面板3项前端已交付 verified(mmg d5918009)
2026-09-23 15:05:52 +08:00

9.4 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 frontend-groupbatch-vehicle-house-panel-gaps 团期详情页「用车/用房」面板：乘车户全选汇总人数 + 确认按钮布局 + 对话入口缺失（3 项前端待办） admin wx(GIT) 前端缺陷 not_required not_required verified mmg d59180090e17c3fe1b9a1a4fb4fde22fc9f91685 2026-09-23 wx 团期详情页用车/用房面板走查反馈，3 项均为纯前端待办：①乘车户全选+人数自动汇总（数据 participantCount 已在 orders 数组里，未被读取）②接送机逐户确认按钮布局（未右对齐）③子订单行缺与定制师对话入口（已有可用的既有后端会话接口 open-group，未接入）。三项互相独立，backend_status=not_required 是因为本文件不改任何后端契约。 | 2026-09-23 mmg 交付:三项全落(全选汇总/右对齐/两面板联系定制师透传 ChatDrawer) 2026-09-23 dev-v3

团期详情页「用车/用房」面板：乘车户全选汇总人数 + 确认按钮布局 + 对话入口缺失（3 项前端待办）

服务: 无后端服务变更（纯前端 UI；第 3 项引用的 hl-user-service /admin/message/chat/open-group 是已存在的能力，本次不新增/不修改） PR: 无（前端尚未提交） Issue: 无（wx 口头/会话反馈，未建 Gitea 工单） 日期: 2026-09-23 影响范围: 管理后台团期详情页「用车」「用房」两个 Tab 面板

⚠️ 关键变化

本文件是待补齐清单，不是"已交付变更"说明——三项各自独立、互不依赖，可分别排期，涉及文件都在 hl-ui origin/v2.1 分支。

一、乘车户「全选」+ 按所选户自动汇总人数

涉及文件: src/views/order-v2/batch/detail/components/GroupVehicleRequirementEditModal.vue（「正式用车需求编辑」弹窗，逐日行区块，第 165-201 行）

现状（实测代码）：

  • 「人数」是 <n-input-number v-model:value="d.headcount">（第 177-186 行），headcountRule（第 375-382 行）只校验"非空且 ≥1"，没有联动逻辑。
  • 「乘车户」是 <n-select multiple filterable :options="memberOptions">（第 190-198 行），memberIdsRule（第 383-388 行）只校验"非空数组"。
  • 两个控件之间没有任何联动，也没有"全选"控件。

可用但未被读取的数据：memberOptions（第 323-333 行）目前只从 props.orders 取 orderId/customerName/contactName/teamNo 组装 { label, value }，没有带出 participantCount。participantCount 其实已经在同一个 orders 数组里（团期订单列表 GB-ADM-003 契约字段），同级的 VehicleHouseholdsSection.vue:71 与 RequirementTab.vue:476 已经在直接读它展示"N 人"——不需要新接口，只是这个弹窗的 memberOptions computed 没把它带出来。

需要的改动（供参考，不限定实现方式）：

  1. 全选：一个按钮/开关把 d.memberOrderIds 置为 memberOptions.value 的全量 value。
  2. 自动汇总：memberOptions 补出 participantCount（或另建 orderId → participantCount 的 Map），选中集合变化时把 d.headcount 自动置为已选各户 participantCount 之和；participantCount 为 null 的户按 0 计。
  3. headcount 输入框保留手动可编辑——自动填充只是给个起点，若某户实际乘车人数与 participantCount（报名人数）不一致（如小孩不占位、分批乘车），管理员仍需手动改。

业务边界：

  • 这里自动算出的人数只是填表辅助，不是权威口径——整团/整日的用车人数汇总另有独立的后端工单在跟（wx/HL#8220，backend），本项做完之后 d.headcount 仍然只是这张表单自己的字段，不代表后端汇总接口上线后的口径一定与这里手填/自动填的值相同。
  • participantCount 为 null 的户参与"全选"时按 0 计入自动汇总，不阻断全选本身（该户仍会被选中，只是不贡献人数）。

二、接送机需求逐户「确认」按钮挪到行右侧

涉及文件: src/views/order-v2/batch/detail/components/VehicleHouseholdsSection.vue

现状（实测代码 + 样式）：

  • 「确认」按钮（canConfirmReq(req) 为真时渲染，第 122-129 行）与车型/状态标签、"XX 人"文字同处一行——.vehicle-households__req-head（第 92 行起）。
  • 该行样式（第 495-500 行）：display: flex; align-items: center; gap: 8px; flex-wrap: wrap;，没有 justify-content 或对按钮单独设 margin-left: auto，按钮紧跟在"XX 人"文字后面，不在行的最右侧。

需要的改动：给 .vehicle-households__req-head 加 justify-content: space-between（把按钮包进一个独立的尾部容器），或直接给「确认」按钮加 margin-left: auto，把它推到行右侧。

业务边界：

  • 只影响 .vehicle-households__req-head 这一处的 TRANSFER 行确认按钮；用房面板 RoomHouseholdsSection.vue 全文没有等价的逐户「确认」按钮（已核查，仅第 127/289 行的注释提到"整团确认"，属另一套交互，不在本项范围）。

三、用车/用房子订单行缺「和定制师发起对话」入口

涉及文件:

  • VehicleHouseholdsSection.vue 的 .vehicle-households__card-head（第 56-77 行）
  • RoomHouseholdsSection.vue 的 .room-households__card-head（第 44-68 行）

两处的 v-for 都已经在 household 上下文里拿到 household.orderId，但都没有任何对话/聊天入口（全文 grep「对话」「chat」「Chat」在这两个组件里零命中，RoomHouseholdsSection.vue 里唯一相关的是两处注释提及"整团确认"，与聊天无关）。

已就绪的后端契约（本次核实，非新增，backend_status=not_required 是因为接口本身没有变化，只是首次要接给这两个面板用）：

POST /admin/message/chat/open-group（hl-user-service ChatMessageController.openGroup，工单 #7211）

  • 请求体 ChatOpenGroupReqVO：{ "orderId": "70123" }——orderId 必填（@NotNull），团期子订单 id，雪花值按字符串传（与本仓其它 19 位 ID 字段一致，避免 JS 精度丢失）。
  • 响应体 ChatOpenFullRespVO（继承 ChatOpenRespVO）：conversationKey（如 GROUP:70123，不含 adminId 对）、peerAdminId、peerName、peerRole、peerRoleLabel、peerOnline、unreadCount、isNew、order（订单卡）、thread（首屏 20 条消息）、unreadTotal（合并未读，本次调用会把该会话标记已读之后的值）。
  • 团期管理员是团队制，不指派到人：定制师这一侧打开会话时，对端固定是「团期管理员」团队占位——peerRole="GROUP_ADMIN"、peerRoleLabel="团期管理员"，不是某一个具体的管理员账号。
  • 准入：该订单当前定制师（CUSTOMIZER），或当前角色持权限码 group-batch:demand:confirm（超管天然通过）；其余角色统一拒绝且零写入。
  • 错误码：缺 orderId → 281012「缺少订单上下文」；不满足上述准入身份 → 281002「无权访问该会话」；该订单不是团期子订单（团期摘要 groupBatchId 为空）→ 281015「该订单不是团期子订单，无法联系团期管理员」。
  • 打开会话之后，同一个 conversationKey（GROUP:{orderId}）继续走通用的两个端点，不区分模块：GET /admin/message/chat/{conversationKey}/messages（上滑翻页取更早历史）、POST /admin/message/chat/{conversationKey}/messages（发消息）。如果车务/房务面板已有复用的聊天组件，直接换 open 端点为 open-group 即可接入，不需要重新对接翻页/发送逻辑。
  • 网关：hl-user-service 的 /admin/message/** 路由已覆盖，不需要新配路由。

业务边界：

  • 用车、用房两个面板的子订单行请求体字段完全一样（都只传 orderId），可以共用同一套"发起对话"组件。
  • 会话按 GROUP:{orderId} 维度建：同一个子订单如果在用车、用房两个面板里都出现，两边打开的是同一条会话，不会产生重复会话或未读数分叉。

七、不影响范围

  • 仅影响：管理后台团期详情页「用车」「用房」两个 Tab 组件（模板/脚本/样式，纯前端文件）。
  • 零影响：
    • 本文件三项都不改后端契约；第三项引用的 POST /admin/message/chat/open-group 是首次被这两个面板消费，接口本身（CUSTOMIZER↔团期管理员团队场景）未做任何变更。
    • 其它已在用 open-group/open-fleet/open-house 的既有调用方不受影响。
    • 团期用车需求的后端保存/校验接口（GroupVehicleRequirementSaveReqVO 等）不受影响——第一项只改前端表单填充逻辑，提交给后端的字段结构不变。

十、相关文档

  • open-group 契约来源：hl-user-service/src/main/java/com/hulalv/user/notification/chat/controller/ChatMessageController.java（工单 #7211）。
  • participantCount 字段来源：GB-ADM-003 团期订单列表契约（src/api/orderV2GroupBatch.js 第 143-160 行注释）。

关联 / 联系人

链接

  • 无 PR / 无 Issue（本文件为纯前端待办清单，未建 Gitea 工单）。

联系人

  • 第三项接口如有疑问：@wx
在新工单中引用 查看 Git Blame 复制永久链接