dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,191 Commits 3 Branches 0 Tags
979a1bfa413e1f2e27137b92bb5fcd5259bfce5f
Commit Graph
67 Commits
Author SHA1 Message Date
yml2213 b666a9c951 fix(consignment): 拼单份额验收收官补寄卖结算钩子 + 手动匹配弹窗三处复核遗留 
- acceptWorkOrderShareAndSettle 最后一个份额把母单转 accepted 的分支，
  此前不释放发布押金也不结算供货货款（两钩子只在统一验收里）：
  现在同口径补上；供货货款传 assignedWorkerId=0（拼单母单无单一接单人，
  份额打手已各自按 share_reward 结算，不会重复付款）
- 手动匹配弹窗：race_condition/unavailable/spec_mismatch/partial_requires_confirm
  四个错误码清空已选并自动重拉列表，数据过期不再死循环撞错
- 手动匹配弹窗库存侧：keyword+pageSize100 透传后端（原来 keyword 是死参数、
  只拉 50 条），300ms 防抖后端搜索；无供货打手时禁用指派选项并在提交前
  再拦一道（原来必 400 死路）；选中订单回显 workerId/workerName
- 凭证核销反馈抽共享 utils/voucher-consume，WorkOrdersPanel 与弹窗共用，
  口径不再漂移（弹窗顺带获得"已提前核销 N 张"提示）
- docs/寄卖系统优化方案.md 记录批次 V

后端 477（+4）/ 前端 50（+1）测试全绿，typecheck / lint / format / check:sql 通过
 2026-09-17 12:45:51 +08:00
yml2213 63837e473b fix(consignment): 复核修复——占库撞 080 CHECK 必 500、指派非卖家双付货款、手动匹配权限门控 
- 占库默认 allocation_status 从自由文本改为「已安排」，不再撞 080 的
  CHECK ('待安排','已安排')；加静态守卫测试（剥注释断言枚举内默认值）
- resolveConsignmentAssignRewardFen 加 assigneeIsSupplier：指派供货卖家本人
  → 报酬=结算价（货款走报酬渠道）；指派别的打手 → 报酬保持原值（货款走
  供货货款渠道），两条渠道互斥，封住平台双付；补行为级测试 + 调用点钉住
- 手动匹配两处入口（库存面板行内按钮、拦截弹窗 footer）统一按
  consignment.fulfill 门控，编辑/作废仍为 manage，与后端权限一一对应
- docs/寄卖系统优化方案.md 记录批次 U

后端 473（+3）/ 前端 49（+1）测试全绿，typecheck / lint / format / check:sql / build 通过
 2026-09-17 12:36:12 +08:00
yml2213 0476339ec4 fix(consignment): 手动匹配订单按钮点了不弹窗（弹窗挂错了位置） 
用户反馈：在库待匹配列表点「手动匹配订单」没有反应。

根因：上一批把手动匹配弹窗挂到了「编辑寄售物品」弹窗**内部**，外层弹窗未打开时
该组件根本没被挂载，点击只改状态、界面无变化。

- 弹窗移到面板顶层（与其它弹窗同级），点击即弹
- 新增静态守卫测试：断言手动匹配弹窗前面不能有未闭合的 Modal（即不能嵌在别的弹窗里）、
  按钮必须真的 setState、open 由该状态驱动；已验证该守卫能拦下错误写法
- 顺带补入口缺口：订单侧原先只在"检测到系统候选"的提醒弹窗里给入口，订单没有任何候选时
  反而进不去手动匹配 —— 工单行内新增常驻「手动匹配现货」（仅待指派/待补资料，
  与后端前置校验同口径）
- 已暂停匹配的现货点按钮会直接 409，改为按钮禁用并提示先打开「允许匹配」开关
- destroyOnClose → antd 6 的 destroyOnHidden（前者已废弃）

验证：前端 typecheck/lint/format/48 例测试/build 全过。
 2026-09-17 12:27:58 +08:00
yml2213 a7a55d6c16 feat(consignment): 客服手动指定现货匹配的界面入口 
后端批次已提供判定/差异/强制留痕与双向读取接口，这里补界面，让客服真的能用上。

- 新增共享弹窗 ConsignmentManualMatchModal：订单侧（匹配弹窗「手动指定现货匹配」）与
  库存侧（寄售仓库行内「手动匹配订单」）共用同一套交互与落地逻辑，避免两套 UI 漂移
- 交互：搜索 → 选中（精确/非精确/规格冲突三档标签 + 字段级差异说明）→ 选交付方式
  （内部现货履约 / 指派供货打手）→ 非精确需勾选确认、冲突需勾选「确认规格不一致」并必填原因
  → 落地；并在落地前提示"现货立刻被占用、点错需撤销寄售履约"
- 判定规则收敛成纯函数 consignment-manual-match.ts（需不需要确认/填原因、能否提交、
  关键词过滤、标签文案）并加 4 例单测
- 服务与类型补齐：fetchWorkOrderConsignmentMatchOptions / fetchInventoryMatchableOrders，
  fulfill/assign 入参增加 allowSpecMismatch 与 matchNote
- 凭证核销失败的提示沿用既有规则（核销失败不能报成功）

验证：前端 typecheck/lint/format/44 例测试/build 全过；两个新接口未登录访问均 401
（路由已挂载、权限位生效）。
 2026-09-17 12:23:30 +08:00
yml2213 ca04e09deb feat(consignment): 客服端凭证链可视化（提报凭证 + 赠送凭证） 
问题：一件寄卖有两类凭证，客服界面只看得见第一类，还是 48x48 一张缩略图，
看不出是主页还是物品；第二类（证明"这件货真送出去了"的赠送完成截图）只在工单验收界面，
客服要证明赠送是否完成得自己跨模块翻，没有任何地方把两类凭证并排呈现。

- 两类凭证分别在哪里：
  提报凭证 = 提报表 screenshots_json（卖家提报时的游戏主页截图，含物品/仓库详情）
  赠送凭证 = 绑定工单的验收资料 work_orders.acceptance_json（冷却结束后上传、客服凭此验收）
- 后端把凭证链从客服两个列表/详情接口一起下发：提报表/库存 → 结果库存 → 绑定工单，
  新增 submissionScreenshots / giftEvidenceImages / giftEvidenceNote / giftEvidenceSubmittedAt /
  giftWorkOrderNo / giftWorkOrderStatus / giftEvidenceReviewStatus（none|pending|accepted|submitted）；
  赠送凭证图从 imageUrls 与 files[].url|mediumUrl|thumbnailUrl 两处取并去重
- 提报凭证口径统一：有来源提报单用提报单主页截图，客服手工入库现货回退库存自身截图，
  前端只看 submissionScreenshots 一个字段，不会拿错
- 前端新增共享组件 ConsignmentEvidenceGallery（缩略图 + 大图预览 + 共 N 张，
  预览用 Image.PreviewGroup items，被折叠的图在大图里仍能翻看）；审核面板把「凭据截图」
  拆成「提报凭证（游戏主页截图）」与「赠送凭证」（带待验收/已验收 Tag + 关联工单 Tooltip），
  仓库面板新增「凭证」列并分组展示，两个详情弹窗同口径（含备注/提交时间/工单号/一句话说明）

真实库验证：赠送凭证解析在构造的工单验收资料上取到 3 张图（imageUrls 1 + files 2）并识别
pending_acceptance → 待客服验收；提报凭证在真实数据上取到 1 张。临时数据已清理。
 2026-09-17 11:22:59 +08:00
yml2213 44de11a3a7 feat(consignment): 一个寄卖单号锚定全流程 + 统一状态机 + 卖家侧确认加好友/提交赠送截图 
问题：一件货身上挂着三套互不相通的状态（提报单审核态、仓库库存态、工单赠送态），
my-items 同时返回两个数组、卖家端分两个列表渲染，同一件货显示两行两个号；
且卖家端只映射了前两套状态，"已出库"之后流程就断了，卖家不知道该干什么。

- 提报单号 SUB… 作为唯一「寄卖单号」从发布锚定到结算（零迁移）；
  listWorkerConsignments 改成一件货一条记录，库存/工单信息挂上去，
  客服手工入库的现货（无提报单）才回退用库存号当锚点
- 新增 domain/consignment-item-stage.ts：把三套底层状态推导成卖家看得懂的一个阶段
  （待审核/已通过待匹配/已匹配-待加好友/冷却中/待赠送/已赠送待审核/已完成/驳回/作废/取消）
  + 一句"下一步做什么" + 能力位（谁能确认加好友、谁该传截图），列表筛选与 KPI 也改由它驱动
- 卖家侧新增动作（以前只有 publish + my-items，卖家只能干看）：
  POST /worker/consignment/items/:submissionId/{confirm-friend,gift-evidence}
  POST /worker/consignment/inventories/:inventoryId/{confirm-friend,gift-evidence}（手工入库现货）
  复用既有工单链路 confirmWorkOrderFriendAdded / submitWorkerOrderAcceptance，
  只加归属校验（不是本人履约的订单 403），顺带白拿"冷却没结束不许提交凭证""必须带图"
- 客服端用同一个号：库存列表/详情补 sourceSubmissionNo（LEFT JOIN 提报单），
  履约/指派写进工单的寄售信息也带上；关键字搜索支持按寄卖单号搜（计数 SQL 同步补 join）

真实库端到端验证：确认加好友 → gift_phase=friend_countdown / friend_added_at 落库 /
gift_available_at 正好 +72h；冷却期内提交截图被拒（work_order_gift_cooldown_active）；
越权操作被拒（consignment_item_not_found）；按寄卖单号搜索命中正确。临时数据已清理。
 2026-09-17 10:57:57 +08:00
yml2213 d6f6219fe9 feat(consignment): 内部现货履约改为停在「待加好友」，由客服确认后进赠送冷却 
需求：发布匹配成功后订单要停在待加好友，客服线下通知加好友、手动确认后才进赠送冷却。

- 新增 parkWorkOrderWaitingFriendAddWithClient：占库落地时把工单停在
  acceptance_mode=friend_gift + gift_phase=material_required 的「待加好友」阶段，
  friend_added_at / gift_available_at / deadline_at 都留空（没有打手在跑，不该背时限），
  并把商品规则里的冷却时长落到工单上（两者都为 0 时补默认 72 小时，
  否则客服确认后会得到 0 秒冷却而立刻可赠送）。
- 履约服务不再传 forceFriendGift（该开关会直接把 friend_added_at 写成当前时间、
  跳过客服确认）；同步删除这个已无调用方的开关，冷却起始事件里的
  skippedWorkerMaterial 改为按是否内部现货履约判断。
- 前端：内部现货单在该阶段显示「待加好友」（原为「待打手提交资料」），
  确认按钮统一为「确认加好友」，确认弹窗补上"先用库存账号加好友、通知进展记备注"的引导。
- 后台备注增加快捷项「已通知加好友」，一键追加「[已通知加好友] 操作人 时间」。
- 阶段文案抽到 utils/gift-phase.ts 以便单测覆盖这条口径。

验证：真实库跑通全链路（停阶段 → 确认加好友进冷却 → 重复确认被拒 → 事件流正确，临时单已清理）；
后端 415 例（412 通过，新增 3 例）、前端 25 例（新增 4 例）全绿。
 2026-09-16 21:02:50 +08:00
yml2213 563e548b2e feat(consignment): 补齐寄卖前端权限门控，收口调拨状态与运营体验 
权限门控（P1-8 剩余）：
- 新增 resolveAdminPermission(sessionPermissions, code)：会话接口的最新权限列表优先，
  接口异常才回退登录时的本地快照；空数组也判无权限，避免"刚被收回权限仍能点"。
- 寄售仓库面板：consignment.manage 控制手动入库/编辑/作废/退单回库/匹配开关（无权限时开关禁用）。
- 寄卖提报面板：consignment.review 控制审核入库/驳回。
- 接单平台页：无 consignment.view 不渲染两个寄卖 tab，并把 URL/localStorage 的旧选择拉回工单页。

数据约束（P2-19 剩余）：
- 迁移 080：allocation_status 历史非法值归位「待安排」（备注留痕）后加 CHECK（待安排/已安排），
  并顺手修正 077 遗留的"收集链接/玩家提交"权限描述文案。
- 编辑接口拒绝直接改 allocationStatus（400 consignment_allocation_status_update_forbidden）。

运营体验：
- 两个面板补 isError 错误态与重试；审核通过/驳回加 confirmLoading 与提交中守卫（防双提交）。
- 待审徽标改用后端真实总数（原来只统计当前页）；编辑弹窗押金不再兜底 ¥100（会误写押金）。
- 履约拦截弹窗冷静期文案不再硬编码"3 天"，改为按商品规则设定。
- 核实并撤回"倒计时时区偏移"误报：deadlineAt 为带 Z 的 ISO，前端无偏移问题。

验证：后端 412 例（409 通过）、前端 21 例（新增 5 例权限解析）全绿，
typecheck / lint / format / check:sql / build 通过；迁移 001→080 在全新空库跑通并在 dev 库应用。
 2026-09-16 20:39:52 +08:00
yml2213 18ac95ca27 feat(worker-hall): 接单大厅支持内部打手可见订单已发布时长标签 2026-09-13 11:14:16 +08:00
yml2213 ffb71f2276 修复接单端过期会话重复请求 2026-08-30 17:32:34 +08:00
yml2213 f20ff3018f feat(打手): 支持个人追加免押额度 2026-08-28 21:36:54 +08:00
yml2213 c3bd6daee2 优化本地Mock接单 2026-08-21 12:39:24 +08:00
yml2213 e6ab139071 修复容器测试并补订单回归 2026-08-21 12:29:19 +08:00
yml2213 d2512ccb6b 调整接单密码强度规则 2026-08-20 16:19:44 +08:00
yml2213 ee79195f47 完善拼单状态与份额验收流程 2026-08-18 18:02:43 +08:00
yml2213 5c7c3e14e3 统一前后端代码格式化配置 2026-08-16 17:27:12 +08:00
yml2213 bc2909d6f2 打手端迁移至独立子域名 2026-08-16 16:08:38 +08:00