 zhaoxing
|
7743d2019c
|
fix:优化再拼一次bug,优化打手端移动端拼单列表显示
|
2026-10-26 16:36:26 +08:00 |
|
 yml2213
|
31a8b6fc65
|
Merge branch 'dev1023' into dev
解决 9 个冲突文件，并修复合并后遗留问题：
- 大厅候选集：采用 FIFO 窗口 + 全部置顶单 UNION（列表与抢单/拼单复核同源）
- 拼单份额：采用多次参与模型（每次参与 INSERT 新份额、requestId 幂等），
取消后可重新参与；移除 HEAD 已废弃的单行 rejoin 逻辑与对应测试
- 工单迁移与成本中心 103–108 编号撞车：合并重写为
109_work_order_share_participation / 110_work_order_hall_and_shop_indexes；
临时库全量执行与重跑幂等验证通过（10 列、唯一键已删、7 个索引）
- 实时补丁：保留个性化字段、置顶重排、分页总数同步；补回 orderTimelineVisible 类型
- 打手大厅：保留 memo 组件化，移植「再拼一次」多份额按钮逻辑
- 全项目表格统一 PercentTable：WorkerOrderShareTable 改造
验证：backend typecheck/lint/check:sql/test(833 pass)、
frontend typecheck/lint/test(172 pass)/build 全绿。
|
2026-10-26 12:10:53 +08:00 |
|
|
yml2213
|
81edf530db
|
fix(worker-platform): 拼单取消后可重入，大厅置顶始终优先
|
2026-10-25 13:08:19 +08:00 |
|
|
yml2213
|
7fdef88ba6
|
perf(worker-hall): 优化百单大厅加载与渲染性能
|
2026-10-24 20:41:58 +08:00 |
|
|
zhaoxing
|
25756901cc
|
add:新增同一个工单同一人可以多次拼单：抢单大厅优化
|
2026-10-24 13:44:34 +08:00 |
|
|
zhaoxing
|
7e1e1f7075
|
add:新增同一个工单同一人可以多次拼单：拼单后按钮固定显示「再拼一次」
|
2026-10-23 16:37:59 +08:00 |
|
|
zhaoxing
|
1d5615f1ae
|
add:新增同一个工单同一人可以多次拼单
|
2026-10-23 15:14:07 +08:00 |
|
|
yml2213
|
fe4d02d136
|
fix(worker-platform): 按工单号搜不到彻底收口 —— 显式单号检索不再被任何排他筛选吞掉
## 修的是什么
线上反复复发的「后台接单平台按工单号搜不到、某些状态尤其明显」，根因不是一处，
而是同一类问题在 5 个地方各留了一半（历次修复都只补了一处，所以总复发）：
1. 状态筛选走运营态派生：拼单母单一旦有人参与，open → in_progress /
pending_acceptance，于是「单号 + 待接单」永远为空（没人参与时反而搜得到），
这正是「有人接单后就搜不到」；非拼单单子被接单后同理。
2. 「单号 + 接单人员 / 分类 / 打手等级 / 创建时间」照样过滤掉目标单
（接单人员是 INNER JOIN 可见集合，不在集合里整行消失）。
d6523635 只在面板查询按钮里清了 状态/赠送阶段/验收模式，这三个没清。
3. 待办通知跳转（buildNotificationActionPath 带 ?workOrderId=）设下的
「定位工单」是 wo.id = X 排他条件，不手点「取消定位」就一直生效，
之后搜任何别的单号都是空 —— 这条路径历次修复从未涉及。
4. AdminLayout 把服务端 operation='remove' 直接判成 mismatch，
绕过了「显式单号不删行」的护栏。
5. 打手端「我的订单」默认页签固定「代练中」，搜索不联动页签、
实时补丁又拿状态当可证伪条件删行 → 打手端同类问题（此前只修了关键词匹配）。
## 修法（收口到单一真源，不再按按钮打补丁）
后端：
- 新增 isExplicitOrderNoLookupKeyword()（工单号 / 平台单号 / SUB·INV·AS·DT）；
- 后台列表筛选抽成纯函数 resolveAdminWorkOrderListFilters()：显式单号检索时
不下推 状态/VIP待补图/验收模式/赠送阶段/接单人员/分类/打手等级/创建时间/定位工单；
- 打手端 resolveWorkerMyOrderStatusFilter()：只放掉状态与 VIP 待补图，
**严格保留 workerSharingId 可见范围**（否则打手能搜到别人的单）。
前端：
- admin-realtime-work-orders.ts：显式单号检索直接判 unknown（含服务端 remove），
remove 的短路移交给判定函数；
- WorkOrdersPanel：单号检索时清空全部排他筛选并提示「已按单号精准检索，自动忽略…」，
通知定位工单时也清掉其它筛选，避免残留；
- WorkerOrdersPage：单号检索自动切「全部订单」；WorkerLayout 走新的
resolveWorkerMyOrderRealtimeVerdict()，与后台同策。
刻意不改（避免越权/召回不可用单）：抢单大厅（候选必须是 open）、
寄卖手动匹配候选（只做未接单整单）。
## 验证
后端 npm run check 全绿：682 pass / 3 skip（新增 6 项）；
前端 npm run check 全绿：138 pass（新增 6 项，含「单号检索 + 实时事件不得删行」，
以及「服务端 remove 不得绕过单号护栏」的回归）；format/lint/typecheck/build 通过。
无数据库迁移。
|
2026-10-12 15:48:30 +08:00 |
|
|
yml2213
|
f4c405d51a
|
fix(worker): 打手端实时补丁不再误删"按工单号搜到的行"，并同步分页总数
这是后台那个"搜工单号搜不到、必须刷新整页"在打手端的同源副本：
WorkerLayout 的 operation = event.operation === 'remove' || !matches ? 'remove' : 'upsert'
只要前端判"不匹配"就删行，而前端关键词匹配器**没有比对工单号**——
后端搜索表达式的第一项恰恰就是 work_order_no（还有 material_json 里更多前端不知道的字段）。
于是按工单号搜索时，该单一旦有实时变更，行就被从缓存删掉、列表变空。
修法与后台侧对齐：
1. 抽出 utils/worker-realtime-work-orders.ts（可单测、无运行时依赖），关键词匹配补上
workOrderNo，并改成三态判定——状态/分类等可证伪维度不符才删行；关键词能找到=match
（允许插入），找不到=unknown（不删不插，只就地更新）。
2. patchWorkerWorkOrderListEnvelope 增删行时同步 data.pagination.total，
修掉"列表空了、分页器还显示有 N 条"。
3. 大厅无限下拉只在第 1 页允许插入，其余页只就地更新。
验证：前端 86 项单测全绿（新增 6 项，覆盖"按工单号搜索+实时变更不得删行"、
unknown 只就地更新、删/插同步总数、无限下拉页边界）。
|
2026-10-01 13:48:05 +08:00 |
|