KCGL/inventory-backend at 263f7ba3a1cb879a49012691345446d0bef95537 - KCGL

Files

yueli 1a8e3e3dc0 feat(borrow): 转交改为整单覆盖 + 双向握手，并修复接收人可见性

一、整单覆盖（修复漏行 / 单内撕裂）
----
transfer_borrow 现在按 borrow_no 定位**整张单**，覆盖全部未还明细；accept 时
整批转移持有权。原先只改传入的那一行，2 明细的单转完会出现两个持有人。

新增 _load_slip_for_update()：按单号锁整单，且按 id 升序取行锁 —— 并发下所有
事务以相同顺序加锁，避免与归还/转交交叉加锁死锁。

二、双向握手
----
· transfer_borrow（发起）：只落一条 PENDING 流水，**不再改主表 current_holder**。
  东西还没到对方手上，责任仍归原持有人 —— 这是与旧实现最本质的区别。
  同一单号已有 PENDING 时拒绝再次发起，避免两个接收人争抢同一批实物。
· accept_transfer：流水置 ACCEPTED，把该单**全部未还明细**的持有人改为接收人。
. reject_transfer：流水置 REJECTED，主表不动。
  两者都强校验「当前登录人 == to_user_id 本人」。

★ accept/reject 刻意**不加 permission_required**：这不是库管职权，而是员工对
  自己名下资产的确认动作，加库管权限会把接收人挡在门外。

三、接收人可见性（OR 过滤）
----
get_records 普通用户过滤原先只比对 borrower_name，接收人在自己的列表里看不到
已经接收的东西。现改为三种关系任一成立：
    ① 我是借用人
    ② 我是**当前持有人**（转交接收后）
    ③ 有一条**待我接收**的 PENDING 转交 —— 东西还在对方手上、主表尚未转移，
       ② 匹配不到，必须单独并入，否则接收人看不到待办、无从确认
ID 与姓名双口径并存，兼容只有姓名没有 ID 的历史行。

列表项附加 pending_transfer（含后端判定的 is_mine）—— 前端 localStorage 里
只有 username 没有 user_id，靠姓名比对既有歧义又不可靠，故由后端标记。

四、验证（合成 2 明细单，25 项断言全通过）
----
· 发起后两条明细持有人均未变（责任未转移）
· 非接收人无法 accept / reject；重复发起被拒
· ★ accept 后**两条明细**持有人一并转移（漏行修复的核心）
· 接收前凭 PENDING 分支可见、接收后凭 current_holder 可见
· reject 后主表持有人不变
· 全程 available_quantity 无变化，库存精确还原、零残留数据

2026-09-17 10:04:12 +08:00