Mimingguang
27ee86ea5f
- #7939 → 8360287a(总览条 scopeFilterHint 两口径文案,scope 已摘除只提示不切) - 月份分组缺陷 → c19923be(默认月组倒序改升序,显式排序仍跟随行序) - batchNo 缺陷 → c6174f2c(仅删显示,keyword 搜索数据链不动) 各自定向 spec 6/6、21/21、9/9 + scoped checkpoint 全绿,hl-admin v2.1 已推。
4.7 KiB
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 | 团期看板月份分组倒序，应按出发日正序 | admin | wx(GIT) | 前端缺陷 | not_required | not_required | verified | mmg | c19923be3f5e3c41b84a7b8acb8a00081df34293 | 2026-09-18 | 纯前端条目，后端零改动。团期看板按月份分组渲染时，月份组的顺序是倒序（11 月排在 10 月之前），与原型「6 月 → 7 月」的正序要求相反。后端 GET /v3/admin/order/group-batch/board 返回的行本身是按出发日期升序的（2026-09-18 测试环境实测，10 行原始顺序 2026-08-20 → 2026-11-26 严格递增），且该接口只有 productId 与 scope 两个入参、不提供任何排序开关，因此倒序是前端分组渲染环节引入的。请前端在按月份聚合后，对月份组按月份升序排列，组内保持后端给的顺序。[mmg 2026-09-18 已实现并验证] batch/index.vue groups 默认分支月组排序由月份倒序改升序（早月靠上），「其他/日期未定」沉底与显式排序跟随 records 首见顺序两分支不动，组内保持后端原序不重排；spec 例改钉「默认升序不随行序+显式排序跟随行序」，定向 6/6+scoped checkpoint 全绿。 | 2026-09-18 | dev-v3 |
团期看板月份分组倒序，应按出发日正序（前端缺陷）
服务: hl-order-service-v3（后端零改动） 页面: 管理后台 团期订单 → 选中某产品 → 右侧「班期总览」列表 接口:
GET /v3/admin/order/group-batch/board日期: 2026-09-18 影响范围: 仅前台渲染顺序；无端点、无出入参、无路由、无 DDL 变化
⚠️ 关键结论
🔵 后端返回的顺序是对的，倒序是前端分组时引入的。 无需等后端改动即可修复。
一、现象
选中产品后，右侧班期列表按月份分组，月份组的排列是倒序：
2026 年 11 月 4 期
2026 年 10 月 4 期
而原型要求的是按出发日正序：
6 月 · 2026 2 期
7 月 · 2026 8 期
月份越早越靠上，与「按出发日期升序」的业务直觉一致。用户看班期列表通常是为了找最近要出的团， 倒序会把最远的团顶到最上面。
二、后端已确认正确（实测证据）
2026-09-18 在测试环境对产品 2100839045562077186（「王骁测试团期产品」，10 个班期）实测
GET /v3/admin/order/group-batch/board?productId=2100839045562077186，
不做任何本地排序，直接打印响应数组的原始次序：
2026-08-20 | 2026-09-03 | 2026-10-08 | 2026-10-15 | 2026-10-22
| 2026-10-29 | 2026-11-05 | 2026-11-12 | 2026-11-19 | 2026-11-26
严格递增，与接口 javadoc 的承诺一致：
GroupBatchQueryController.java:79—— 「返回命中/未命中/孤儿三类行，按出发日期升序」
传 scope=ALL 与不传 scope 两种情况下顺序相同。
三、后端没有可以把顺序倒过来的开关
GroupBatchQueryController.java:85-88 该接口的全部入参只有两个：
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
productId |
Long | 是 | 产品 ID |
scope |
String | 否 | ONGOING / FINISHED / ALL，缺省 ALL；只影响过滤，不影响排序 |
没有 sort / order / direction 这类排序入参。 因此前端拿到的一定是升序数组，
倒序只可能来自前端自己的分组或排序逻辑。
页面上那个「排序」下拉框如果是前端本地排序，请一并检查它的默认值。
四、期望的修复
前端按月份聚合之后：
- 月份组按月份升序排列（2026-10 在 2026-11 之前）；
- 组内保持后端返回的原顺序（后端已是出发日升序，不要再排一次，也不要反转）。
五、后端需要做的
无。 本条目不涉及任何后端改动、接口变更或网关路由调整。
相关
- 同一页面另有一条后端问题已立单：统计条
GET /v3/admin/order/group-batch/summary在productId有值时缺省把班期范围收窄为ONGOING（只算未结束的）， 而响应不声明自己过滤过，导致左侧产品卡片显示「10 期」、右侧总览显示「共 8 期」两个数字打架。 见wx/HL工单 #7939（已指派 jw）。该单会给summary响应补effectiveScope与filteredOutCount两个字段，前端届时需要消费并提示「仅显示未结束班期（另有 N 期已结束）」。 本条目与 #7939 是两件独立的事，排序问题不依赖 #7939 落地即可修。