duxingchen/KCGL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,077 Commits 5 Branches 0 Tags
8db33fdf400de8d732f3da6953564c7ac0fe2b99
Commit Graph

1077 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
yueli
8db33fdf40 V3.88,9.20推送 2026-09-20 17:01:52 +08:00
yueli
3bb5fc6eb8 fix(outbound): 执行校验兼容无 base_id 的历史单据，修复老单必然被拒 
2026-09-10 预占改造（b57c21a）之前建的单，items_json 里没有 base_id。
这类单只要在改造上线时仍处于「已通过待执行」状态，就再也执行不了：

  批准侧 build_approval_index() → identity_key(base_id, name, spec)
    无 base_id → 退化成 ('name', 名称, 规格)
  扫码侧 stock_identity()      → ('base', id)
两侧键不同构，**永远不相等**，verify_scanned() 必然抛
「扫码物料【…】不在该申请单的批准明细中，禁止出库」——批的就是这件货。

identity_key() 的文档本就把 (name, spec_model) 写作「历史数据的兜底」，
只是校验时只有批准侧降了级、扫码侧没有，两侧因此错开。

实测（APR-OUT-20260909-1313-0007，建于 09-09，改造上线前一天）：
  批准侧 ('name', '派里肯安全箱1600（黑色）', 'PS-9640B001-black')
  扫码侧 ('base', 3012)

修复：
  · 新增 stock_name_spec() —— 库存行 → 名称型身份键，刻意丢掉 base_id
  · 新增 build_legacy_approval_index() —— 无 base_id 的历史明细旁路索引
  · verify_scanned() —— 主索引落空时用库存行名称+规格再比一次；命中则
    改用**批准侧的键**继续，使 acc 累计与 approved_idx 的批准量同口径

安全边界（关键）：降级只对真正来自老单据的名称型键放行，白名单是
legacy_idx 而非 approved_idx 本身——build_legacy_approval_index() 只收
identity_key() 产出名称型键的明细，有 base_id 的一律跳过；名称与规格皆空
的明细直接丢弃，绝不退化成「任意物料都能匹配」。无老单时该索引为空集，
降级分支恒不命中，行为与改造前逐字节一致。

影响范围：当时处于 status=1 的老单全库仅 1 张（即上述单号）。其余 358 张
老单（已完成 327 / 已驳回 9 / 已完结 22）均为终态，不受影响——它们在改造
上线前就已执行完毕。

实测验证：
  T1 老单 360 + 扫批准范围内物料     修复前必拒 → 修复后通过
  T2 老单 360 + 扫单外物料           仍拒绝
  T3 老单 360 + 数量超批准           仍拒绝
  T4 现代单 + 扫批准范围内物料       通过（旁路索引 0 键，未受影响）
  T5 现代单 + 扫单外物料             仍拒绝

副作用改善：降级后标签改用批准侧的键，超量报错从「物料#3012」变为
「派里肯安全箱1600（黑色）（PS-9640B001-black）」，可读性提升。
 2026-09-20 16:43:37 +08:00
yueli
4f922a55f3 V3.87,9.20推送 2026-09-20 15:11:10 +08:00
yueli
d7f7548cee fix(outbound): 库存分配按 base_id 合并需求，修复重复行导致的假性库存不足 
_allocate_bom_requirements 在整轮 for req 循环中复用同一份可用量快照
（rows_by_base 建好后不再更新），而 for 循环本身不按 base_id 去重。同一
物料以多行进入时，每行都从同一份快照重新分配一遍，把同一个 stock_id
重复分配 N 次，累计分配量可超过该行真实可用量。

超配在分配阶段不会暴露，直到 reserve_for_items 的二次校验
（take > avail）才抛错，报「可用库存不足（需 X，实剩 Y）」，而实际库存
充足。实剩为 0.0 是当最大候选批次的可用量恰好等于单行需求时的收尾形态。

重复行来自正常业务，非脏数据：
  - 购物车里同一物料的多批次就是多行（Selection.vue 提交时只带
    base_id + quantity，stock_id/source_table 被丢弃）；
  - BOM 明细里同一子件被多处引用（前端 requirements 按 child_id 不去重）；
  - 调拨 / 补发等拆行场景。

修复：在函数入口按 base_id 合并 reqs、required_qty 求和。分配语义不变
—— 分配器本就按 base_id 拉全量批次行、降序分配，输入里的 stock_id 从来
就被忽略。

选在此处收口而非合并调用方的 items：_allocate_bom_requirements 是全系统
库存分配的唯一权威入口（出库与借库都经 reserve_for_items 走到这里），
一处修改同时覆盖两条链路。

实测（base_id=711，四个批次可用量合计 124）：
  三行各 30  修复前 ERROR(需30/实剩10) → 修复后 OK，2117 出 70 + 1182 出 20
  两行各 30  修复前静默超配(两行都绑 2117) → 修复后 OK，合并为 2117 出 60
  十行各 30  修复后报真实缺口「需 300，可用 124」（走正常缺料分支）
 2026-09-20 15:09:14 +08:00
yueli
9ea79a55f8 V3.86,9.18推送 2026-09-18 14:41:53 +08:00
yueli
26a1857acb fix(purchase): 待采购清单的参考价格改按 material_list:referencePrice 管控 
修复一个权限旁路：待采购清单的「参考单价」原本后端无条件返回、前端列也没有
任何门控，而 material_list:referencePrice 只授予 SUPER_ADMIN 与 SUPERVISOR。

结果是 WAREHOUSE_MGR(库管) / INBOUND(入库员) / SALES(销售) 虽然都持有
inbound_purchase:pending_pool、能打开待采购清单，就会看到参考价格 —— 而这个
数字他们在物料列表里是被挡住的。等于本页面成了绕过该权限的后门。

参考价格来自 material_base.reference_price，与物料列表同源，因此复用同一个
权限码管控，不另造新码（同源数据用同码，口径才不会漂）。

改动：
- 后端 get_pending_purchase_pool 新增 include_reference_price 参数，
  fail-closed 默认 False；无权限时**整个字段不返回**而不是给 None
- 新增 _has_material_reference_price_perm()，判定方式与既有的
  _filter_purchase_prices 保持一致（超管/主管放行 + 逐个权限码比对）
- 前端「参考单价」列加 hasPermission 门控，TS 类型改为可选

★ 只挡前端等于没挡（接口仍然裸奔），前后端必须同时改。
 2026-09-18 14:36:02 +08:00
yueli
970c03fb44 feat(material): 基础信息双胞胎页面：移除人工「标记已采购」，改自动「采购在途」 
list.vue 与 buyOdoo.vue 同步改造。这两个文件是手工维护的副本、不是共享组件，
改动必须两边都做 —— 本项目已多次因只改单边导致同一 bug 在另一页长期存活
（参考价格脏检查、表单禁用守卫、发起采购申请按钮等都曾漏同步）。

改动：
  - 移除「标记已采购」按钮、handleMarkOrdered 函数与 markWarningOrdered 引用
  - 操作列改为只读 el-tag「采购在途」，由后端 isPurchasing 派生
  - 预警状态列降级：缺货但已有在途采购单时显示蓝色「缺货(已采购)」而非红/黄

★ 降级只改前端展示，后端 warningStatus 原样保留 —— 预警强排
  （enableWarningSort 的 order_by case()）依赖它，改后端会连带影响排序。

★ 顺带修掉一个历史问题：前端 `scope.row.warningOrdered` 这个字段后端从未输出过
  （后端只给 isOrdered，且列表接口根本没查这一列），所以那个 disabled 的
  「采购在途」按钮从来不会显示，用户标记后永远看不到已标记状态。
 2026-09-18 14:31:22 +08:00
yueli
70dd257392 feat(purchase): 采购申请弹窗支持批量建单与商家链接一键跳转 
批量建单：
  openCreateDialog 新增 batchItems 分支 —— 待采购清单勾选多个物料时，
  明细表一次性铺成 N 行，实现一单多品的合并采购。单条与批量共用
  fillRowFromPrefill 做字段映射，不各写一份。

商家链接一键跳转：
  输入框加后置按钮，点击在新标签页打开，方便采购员比对价格。
  ★ 链接先过 safeHref 白名单（只放行 http/https）—— 该字段由用户自由填写，
    直接交给 window.open 会让 javascript: 之类的伪协议被当成代码执行。
    非法时按钮置灰，不做静默失败。

交接方式：
  单行与批量统一走 localStorage（query 里只传一次性 key，取完即删），
  不经过 URL。原因：material_base.purchase_link 是 text，实测已有 516 字符的
  真实外链，走 URL 会撞上长度上限并被静默截断。曾经单行走 query 时被迫引入
  一个「链接多长就不带」的硬编码阈值，导致同一物料单行跳转带链接、批量跳转
  不带 —— 现在两条路径统一，无长度上限。
 2026-09-18 14:31:14 +08:00
yueli
690ee2c81d feat(purchase): 新增「待采购清单」页面 
路由 router/index.ts：
  /purchase 下新增子路由 pending（name: PurchasePendingPool）。
  ★ 父路由刻意不加 permissions —— 加了会让没有 pending_pool 权限的用户
    整个「采购管理」模块从侧边栏消失。

页面 views/purchase/PendingPool.vue：
  筛选栏 + 表格 + 分页，列含产品图、规格、当前库存、在途、有效供给、
  预警、建议采购量（tooltip 展示完整算式）、参考单价、采购链接、操作。
  采购链接渲染走 safeHref 白名单，非法地址不渲染成可点击链接。

api/purchase.ts：
  新增 getPendingPurchasePool 与 PendingPoolItem 类型。

★ 需告知业务方的可见变化：「采购管理」从扁平单项变为可展开子菜单
  （Sidebar 在子路由只有 1 个时渲染 el-menu-item，2 个时渲染 el-sub-menu）。
 2026-09-18 14:31:07 +08:00
yueli
b4445f07d9 feat(material): 物料列表新增「采购在途」自动标识，预警邮件改用活跃单静音 
base_service.get_list：
  新增 isPurchasing 字段，与待采购池共用同一份活跃单判定。放在预警权限
  判断之外 —— 能看到物料列表的人都该知道这个物料已经在采购了。

inventory_task：
  静音条件从人工标记 is_ordered 改为「该物料无活跃采购单」。

★ 为什么必须同时改邮件：预警邮件由出库执行流程触发（outbound_service 出库
  完成后的调用），功能是活的；而它的静音入口（前端人工「标记已采购」）随本次
  改造一并移除。若不改这里，用户会彻底失去静音能力，每个缺货物料在每次出库后
  都会发信。自动判定在建单时静默、单据驳回或强制结案后自动恢复，比人工标记准。

两张表的判定口径都由 utils/purchase_activity.py 提供，不各写一遍。
 2026-09-18 14:31:00 +08:00
yueli
dec33b685c feat(purchase): 新增待采购池接口（防重复采购） 
GET /api/v1/purchase/pending-pool：找出「有效供给仍低于预警线」的物料。

  有效供给 = 物理总库存 + 在途量
  过滤规则 = 有效供给 <= 红/黄阈值 才进池
  建议采购量 = max(1, 目标阈值 - 有效供给)

★ 为什么不用「有活跃单就排除」：红线 10、库存 0、某采购员只建了一张
  数量 5 的单时，该物料会立刻从池中消失，剩下 5 个缺口永远无人认领。
  改为按量计算后它继续留池，suggested_qty 自动降到 5。

★ 用 <= 而非 < 是与业务方确认后刻意维持的口径（与物料列表预警、预警邮件
  同源），勿擅自改成严格小于 —— 只改本接口会造成「列表亮黄灯、池子却排除」
  的撕裂，真要改必须三处一起动。代价是恰好等于阈值时建议量落到保底的 1，
  前端 tooltip 已单独说明，不展示算不成立的错误算式。

权限：新增 inbound_purchase:pending_pool（注册为 sys_element 而非新建
SysMenu）。因 ensure_default_permissions 在角色已有权限时整段跳过，另写了
存量角色自动迁移，并按源行镜像 company_name 避免跨公司作用域泄漏。
 2026-09-18 14:30:53 +08:00
yueli
fc5e62c848 feat(purchase): 新增「活跃采购单」判定与在途量计算模块 
防重复采购的唯一真相源。刻意回答两个不同的问题，别混用：
- active_purchase_exists()  有没有人在买？      → 展示用
- in_transit_subquery()     已经买了多少还没到？ → 算术用

活跃单定义：status 0/1，或 status=3 且累计入库 < 采购量。
status=4（强制结案）刻意不在其中 —— 短交不补发、来料拒收不补发这类
异常单永远达不到采购量，靠库管强制结案解锁，避免物料被永久占用。

「部分到货」无需改表即可算出：StockBuy.request_id 早已存在，且
StockBuy.in_quantity 是入库原始量（不被出库扣减，区别于 stock_quantity），
按 request_id 聚合即得每张单的累计到货量。
 2026-09-18 14:30:40 +08:00
yueli
caaa1571d4 V3.85,9.18推送 2026-09-18 10:17:05 +08:00
yueli
1b6a6f5c19 fix(return): 还库签名文案统一为「领用人」，消除与页面标题的口径冲突 
同一签名位的四处文案不一致：页面标题（第 7 行）写「领用人签字」，
而正文提示（125 行）与校验报错（391 行）写「库管员」、占位文案
（158 行）写「库管签名」，用户无法判断该谁签。

全部统一为「领用人」。其中第 125 行原为「签字确认入库」，与本节
分节标题「还库确认」自身矛盾，一并改为「签字确认还库」。
 2026-09-18 10:15:18 +08:00
yueli
b4e43d641a V3.84,9.18推送 2026-09-18 10:10:12 +08:00
yueli
ac22c9959b feat(material): 基础信息(Odoo)补回「出库/借库需审批」列 
buyOdoo.vue 是 list.vue 的手工副本。93f1497 / 4146f35 给 list.vue 加了
「出库/借库需审批」列，未同步到 Odoo 页 —— isApprovalRequired 在
list.vue 出现 9 次，在 buyOdoo.vue 为 0 次，该页既看不到也改不了这个开关。

补上表格列（带切换开关与操作权限守卫）、列显示开关、columns 与
permissionMap 条目、toggleApprovalRequired 函数及 batchSetApprovalRequired
接口引用。
 2026-09-18 10:07:27 +08:00
yueli
825c088e98 feat(material): 基础信息(Odoo)补回「发起采购申请」入口 
buyOdoo.vue 是 list.vue 的手工副本。31903bd 给 list.vue 弹窗加了
「发起采购申请」，未同步到 Odoo 页，两个页面的编辑弹窗头部不一致。

补上弹窗头部链接、createPurchaseForMaterial 函数及 ShoppingCart 图标。
 2026-09-18 10:07:24 +08:00
yueli
f2bb95becc fix(material): 基础信息(Odoo)补回表单禁用权限守卫 
buyOdoo.vue 是 list.vue 的手工副本。68fd93b 给 list.vue 加了 formDisabled
（无 material_list:operation 权限时整个表单只读），未同步到 Odoo 页。

列表页的「编辑/新增」按钮虽有权限守卫，但 URL 深链 ?edit_id= 不受守卫，
可直接打开 Odoo 页弹窗：字段能改、确定能点，提交后才被后端
@permission_required('material_list:operation') 拦下，用户白填一遍。

补上 formDisabled computed 及表单、确定按钮两处绑定，与 list.vue 对齐。
 2026-09-18 10:07:21 +08:00
yueli
243355bc68 fix(material): 基础信息(Odoo)补回参考价格脏检查白名单 
buyOdoo.vue 是 list.vue 的手工副本。8791914 修复「参考价格不可改」时只改了
list.vue，同一个 bug 在 Odoo 页存活至今：

- 只改参考价格：payload 无变更，提示「没有检测到数据变更，无需保存」
- 连带改其他字段：提示「修改成功」，但 payload 不含 referencePrice，价格未入库

compareFields 补上 referencePrice，与 list.vue 对齐。
 2026-09-18 10:07:18 +08:00
yueli
eafdf992c7 fix(borrow): 借还记录「归还人」列错标成了经手库管，拆成两列 
问题
----
列表里那一列标着「归还人」，读的却是 trans_borrow.return_operator —— 而该字段
存的是**办理还库的库管**，不是来还东西的人。两者本就是不同的人：
  · returner_id（trans_borrow_return）—— 把东西交回窗口的人，已校验 == 当时持有人
  · return_operator                    —— 经手办理的库管
实测（借用行 120）：return_operator = 杜邢宸/duxingchen（库管），
而实际归还人是 returner_id = 21（测试）—— 页面却显示成了「杜邢宸」。

改动
----
一、后端 get_records 增补 returners：从 trans_borrow_return 取 returner_id 并
    反查 sys_user 得到姓名（去重按明细挂回）。批量查一次，不做 N+1。
二、前端拆成两列，各自名副其实：
      「归还人」   ← returners（后端新增）
      「经手库管」 ← return_operators（原列改为正确标签）
三、顺带修展示口径：return_operator 存的是**完整 username**（高闯/gaochuang），
    未按全站口径截断。_display_borrow_operator 现统一归一到展示名
    （数字 id 反查 / 姓名、斜杠前段 / 已是展示名 原样），并修正其 docstring
    —— 它原本也把该字段称作「归还人」，是同一个误解的源头。

★ 历史数据的现实
  实际归还人流水是二期才建的，**历史归还没有这个记录**。这部分行的「归还人」
  显示为空并挂 tooltip 说明「该笔归还发生在实际归还人记录上线之前」——
  刻意不拿库管的名字顶上，那正是本次要修的错。

验证
  BOR-20260918-0001 → 归还人=['测试']、经手库管='杜邢宸'  ✓ 两者分开
  BOR-20260914-0001 → 归还人=[]（历史）、经手库管='高闯'    ✓
  归一化：'高闯/gaochuang'→'高闯'、'21'→'测试'             ✓
  前端 vite build 通过；本次无需 DB 迁移。
 2026-09-18 09:43:25 +08:00
yueli
e3fe1fc12a feat(borrow): 借还记录「已归还」页签改为按归还时间倒序 
问题
----
三个页签共用同一套排序（有限期单在前 → 最早应还时间 ASC → 最早借出时间 DESC），
这套「优先关注快到期/逾期」的逻辑对「未归还」是对的，但对「已归还」正好**
反了**：已归还列表要回答的是「最近还了哪几笔」，而按应还时间排会让最近刚还的
那几笔排到最后。

改动
----
order_subq 增加 max_return_time（单号内**最晚**一次归还时间）作为排序键，
并按页签分流：
  · 已归还     → nullslast(max_return_time DESC)，borrow_no DESC 兜底保证稳定
  · 全部/未归还 → 原三级排序不变

★ 为什么取「最晚」而不是「最早」一次归还时间
  多明细分批归还时，整单结清的那一刻才是有意义的节点；且与主行「归还时间」列
  的展示口径一致（前端同样取 latest），排序依据与可见值不会打架。

验证（真实数据）
  已归还页签：09-15 11:41 → 09-14 16:02 → 09-09 11:46 → 09-08 13:22 →
              09-04 17:26 → 09-04 09:45 → 09-03 15:25，第 2 页续 08-27 → …，
              严格递减且**跨页连续**；
  未归还页签：排序与改动前完全一致（回归确认）。
 2026-09-18 09:34:45 +08:00
yueli
ccdd6e7306 fix(purchase): 商家地址链接放宽为 text，修超长链接保存失败 
现象
----
采购管理新建采购申请时粘贴电商商品链接报错。实测该链接 **516 字符**，而
purchase_request.supplier_link 是 varchar(500) —— 超出 16 个字符，
PostgreSQL 直接拒绝（value too long for type character varying(500)）。

★ 为什么用 text 而不是把 500 调大
  电商外链（淘宝/1688）普遍带很长的跟踪参数，长度没有稳定上界：本例已 516，
  再叠加一轮营销参数就可能破千。任何有限的 varchar(N) 都只是把报错往后推，
  而且**截断是静默的** —— 用户只会觉得「链接打不开」。
  同 material_base.purchase_link 的处理（那边一开始就用 text）。

附带确认（全部扫描，无需改动）
  从数据库层面扫了所有「有长度上限、且列名像 link/url/photo/image/
  signature/path」的列：
    · purchase_request.supplier_link(500)  ← 本次唯一真正有问题的
    · sys_menu.path(200)、sys_warehouse_location.full_path(500)  内部生成数据
    · stock_adjustment.linked_sku(100)/linked_outbound_no(50)     SKU 与单号
  用户粘贴外链的列仅此一处。

迁移用 DO 块先判断当前类型，可重复执行；含核对段与回滚段。
验证：把那条 516 字符的真实链接写入再读回，长度一致、内容未截断。
 2026-09-18 09:34:44 +08:00
yueli
1eaa203eba fix(db): 修正存量「归还时间/报废时间」的 8 小时时区偏差（附自检） 
问题
----
process_return 与 scrap_sources.deduct 原先用 datetime.now()（容器本地时间，
Docker 默认 UTC）写 return_time / operation_time，而同一行的 borrow_time 由
beijing_time() 写入 —— 同一行两个时钟，差 8 小时。

实测（开发库）trans_borrow 有 53 行呈现「归还时间早于借出时间」这种物理上
不可能的数据，例如 id=80 借出 09-09 11:04、归还 09-09 03:46。

代码侧已修（f7c49f4），新数据已是北京时间 —— 本次只处理存量。

★ 脚本刻意做了「先自检、后修正」的两段式
  服务器 API 容器的 TZ 未必是 UTC（若本就是 Asia/Shanghai，datetime.now()
  一直是北京时间，则**根本无需修正**）。若不做自检直接 +8h，会把正确的时间
  改错。故第 0 步先输出：异常行数、以及按分界切出的「UTC 段/空档/北京段」
  三段计数，由使用人据结果决定是否执行第 2 步。

★ 分界与幂等性都在脚本里写明
  · 分界 = 修复代码在该服务器**部署生效的时刻**（不是提交时刻），需按实际调整；
  · 脚本**不幂等** —— 重复执行会再加 8 小时，已显式警示并给出回滚写法。

开发库已按此逻辑修正：53 行 trans_borrow + 1 行 trans_scrap，
修正后「归还早于借出」为 0，抽样时间落在正常工作时段。
 2026-09-18 09:27:17 +08:00
yueli
91c4ae85db V3.83,9.17推送 2026-09-17 13:40:56 +08:00
yueli
191724a176 fix(outbound): 修复扫码出库 500 —— applicant_id 用了尚未赋值的 approval 
现象
----
所有扫码出库报 500（前端 create.vue 提交即失败）。

根因
----
上一个提交把 'applicant_id': approval.applicant_id 写进了 common_data，
但 common_data 构造在第 234 行，而 approval 直到第 269 行（「强制按单出库」
那一段）才查询赋值 —— 典型的变量先用后赋，直接 UnboundLocalError。
它影响的是**每一条**出库请求，属于必然复现而非偶发。

修复
----
把赋值移到 approval 取出并校验**之后**：common_data['applicant_id'] = ...
并在原处留注释说明为什么不能写在字典字面量里，避免后人搬回去。

★ 我的测试为什么没抓到
  上一轮只测了「退回 → 补发」这条路径，而 applicant_id 的写入在**扫码出库**
  路径上 —— 两条路径不重合，所以漏了。本次补测了完整的
  「出库申请(预占) → 扫码出库(扣减)」链路。

验证（6 项断言全通过，走真实接口链路）
  申请单创建（status=1，申请人=12，预占 stock_buy#2058 两件）
    → 扫码出库不再抛 500
    → 出库明细生成且 applicant_id = 12（不再是 NULL）
    → consumer_name 照常写入
    → 审批单置为已完成
    → 库存实际扣减 2
  清理后库存与数据零残留。

  ★ 顺带在真实数据上得到印证：生产库中已有一笔由业务方重试成功的出库
    （OUT-20260917-1333-0001），其 applicant_id 正确等于所关联申请单的申请人。
 2026-09-17 13:35:47 +08:00
yueli
07567d2f76 fix(outbound): 「补发给谁」改为必选，并按原申请人精确预填 
· 预填顺序改为：① 原出库明细记录的 applicant_id（创建出库时从审批单带出，
  主键无歧义）→ ② 历史单据该字段为 NULL 时，退而按原领用人姓名**唯一命中**
  预填；重名一律留空。
· 「补发给谁」改为**必选**：提交前校验，未选即拦下并提示。
  不再有「留空则挂当前操作人」的兜底 —— 那会把别人的需求记到库管名下。
· 文案同步：明确写「必须选择：补发是原申请人的需求，不能挂到办理退回的库管名下」。
 2026-09-17 12:07:21 +08:00
yueli
0005a689dc fix(outbound): 补发申请人取原申请人，绝不再回退为库管 
问题
----
上一版在库管未指定「补发给谁」时，把补发单申请人回退成了**当前操作人（库管）**。
但补发是**原申请人的需求**，挂到库管名下逻辑不通 —— 那张单会出现在库管的
「我的申请」里，而真正该拿东西的人什么也看不到。

根因
----
trans_outbound 只有 consumer_name（**扫码时前端自由填写**的领用人/客户名，
既不可靠也可能是外部客户），没有任何指回原审批单的关联，所以当时只能退而求其次。

根治
----
一、trans_outbound 新增 applicant_id，**创建出库时从关联审批单带出**
    （request_id 已强制必填、approval 恒非 None，故新单据必然有值）。
    落这一列后，「退回 → 补发」即可自动找回真正的原申请人。
    ⚠ 存量行为 NULL —— 存量出库与其来源审批单之间没有任何可用关联，无从回填。
      刻意留 NULL 而不是按姓名猜（consumer_name 是自由文本，会重名错绑），
      与 dispatch_operator 同一取舍：宁可留空，也不猜。

二、退回接口的申请人优先级改为：
      ① 前端显式指定 reissue_applicant_id
      ② 原出库明细记录的 applicant_id（真实原申请人）
      ③ 都没有 → **报错要求指定**
    ★ 彻底移除「回退为当前操作人」—— 那正是本次要修的逻辑错误。

三、出库列表明细返回 applicant_id，供前端精确预填。

验证（9 项断言全通过）
  · 新单据 → 申请人 = 原申请人(12)，绝不是库管(7)
  · 显式指定优先于原申请人
  ★ 历史单据未指定 → 接口拒绝、要求选择「补发给谁」、整笔回滚、
    且**未生成任何挂在库管名下的补发单**
  · 历史单据 + 显式指定 → 正常
  库存与数据零残留。
 2026-09-17 12:07:21 +08:00
yueli
05524c988a feat(outbound): 退回弹窗增加「补发给谁」选择器 
· 勾选「需要补发」后出现「补发给谁」下拉（filterable + clearable），
  并自动带上补发数量。
· 预填策略：按原领用人 consumer_name **唯一命中**才预选；重名一律留空让现场
  自己选 —— 与借用人回填同口径，宁可多一步也不猜错人（补发单会挂到错的人名下）。
· 留空时后端回退为当前操作人，文案已写明。
· 人员名单**勾选补发时才加载**（多数退回不需要补，避免无谓请求），加载后缓存。
· 新增 api/common/users.ts 的 getActiveUsers()：走中性的
  /v1/common/active-users，而不是复用借库专用路径。
 2026-09-17 12:01:12 +08:00
yueli
27e5589a5e feat(outbound,common): 补发可指定「补发给谁」+ 抽出通用人员名单接口 
一、补发申请人可选择（原单退回）
   退回接口新增 reissue_applicant_id：
     ① 前端指定 → 校验用户存在后落库；
     ② 未指定 → 回退为**当前操作人**（原行为不变，向后兼容）。
   为何不自动推断原申请人：trans_outbound **没有申请人字段，也没有指回原审批单
   的关联**（扫码出库时只把审批单状态置为 3），按 consumer_name 反查会重蹈
   「重名错绑」的覆辙（借用人姓名回填那轮刚踩过）。故把选择权交给现场，不猜。

二、抽出中性人员名单 GET /api/v1/common/active-users
   实现抽到 common.active_user_options()，借库的 /transactions/borrow/users
   改为调同一函数 —— 实现只有一份，但出库补发走**中性路径**，不再出现
   「出库为什么在调借库的接口」这种跨模块语义错位。
   仅要求登录、只返回 id 与姓名（与 /auth/users/approvers 同一处理）。

★ 本次无需 DB 迁移：未新增任何列，补发申请人是复用已有的
  outbound_approval.applicant_id。

验证（打桩/真实 token 直连接口，12 项断言全通过）
  · 名单只含 id/name，无邮箱/角色/部门；借库原路径返回值与新路径完全一致
  · 指定「补发给谁」→ 补发单申请人 = 指定的人；备注仍含原领用人
  · 不指定 → 回退为当前操作人
  ★ 指定不存在的用户 → 被拒，且整笔退回回滚（流水未落库）
  库存与数据零残留。
 2026-09-17 12:01:11 +08:00
yueli
9d187593eb feat(outbound): 退回弹窗增加「需要补发」勾选与补发数量 
· 退回对话框新增「退回后自动生成补发单」勾选框 + 补发数量（勾选时默认 = 本次
  退回量，可调小；上限即退回量）。
· 文案明写两条关键后果：生成的是**免审批**出库单；**库存不足时整笔退回会一并
  取消**，取消勾选即可只做退回过账 —— 避免库管对着失败提示发懵。
· 提交前做同口径前置校验（数量 > 0 且 <= 退回量），不白跑一趟。
· resetReturnDialog / openReturnDialog 同步重置这两个字段。

默认**不勾选**：有些退回是项目结束退还，根本不需要补，不该默认给所有人挂上。
 2026-09-17 11:56:39 +08:00
yueli
7071c89305 feat(outbound): 原单退回后可自动生成补发单 
背景
----
原单退回只做两件事：良品加回库存 / 不良品转在管台账。但**申请人的需求并没有
被满足** —— 东西交回来了（甚至还是坏的），系统却不提醒任何人、无单据承载
「我要重新领一份」，退回与后续再出库之间也毫无关联。现场只能靠人记住再手建
一张出库申请，而那张单与原单看不出任何关系。

改动
----
· outbound_approval 新增 source_return_id（非空 = 补发单），把「退回 → 补发」
  串成闭环。
· POST /inbound/stock/return-from-outbound 新增 need_reissue / reissue_qty：
  勾选即自动生成一张**免审批**出库单（status=1，直接进入待执行），
  沿用原单出库类型，并关联回本笔退回。

★ 为什么只存退回单 ID，不加 is_reissue 布尔列
  「是不是补发」完全由来源是否存在决定，再加一列就是同一事实的两处存储，
  必然有不同步的一天。也不冗余存原出库单 ID：trans_return 已有 outbound_id。

★ 库存不足 → 整笔回滚（关键取舍）
  补发走 reserve_for_items(strict=True)，与出库申请同一口径。不足时抛错，
  退回也一并回滚 —— 若只让补发静默失败，「需要补发」的意图就丢了，
  那正是本功能要解决的问题。库管看到提示后取消勾选即可只做退回过账。

★ 一个被发现的数据约束（改变了原设计）
  原打算把补发单的申请人设为「原出库单的申请人」，但 **trans_outbound 既没有
  申请人字段，也没有指回原审批单的关联**（扫码出库时只把审批单状态置为 3）。
  按 consumer_name 反查会重蹈「重名错绑」的覆辙。故申请人取**当前操作人**，
  原领用人写入备注供人工追溯。
  ⚠ 若业务要求补发单挂在原领用人名下，需要前端在退回弹窗里加一个「补发给谁」
    的人员选择 —— 请确认是否需要。

验证（打桩 JWT 直连真实接口，22 项断言全通过）
  勾选补发 → 免审批单生成、关联退回、预占库存、原领用人入备注；
  不勾选 → 不生成补发单、良品正常回库；
  ★ 库存不足 → 接口拒绝且**退回流水/补发单/退回额度全部未落库**（整笔回滚）；
  补发量 > 退回量被拒；库存与数据零残留。
 2026-09-17 11:56:38 +08:00
yueli
483fb5336a V3.82,9.17推送 2026-09-17 11:41:22 +08:00
yueli
a739f9c889 feat(material): 采购链接在编辑弹窗内可直接跳转，无需复制网址 
体验问题
----
原先只能在编辑弹窗的输入框里看到网址，要跳转得复制出来、另开标签页、粘贴 ——
多三步，且现场场景下很容易贴错。

改动
----
输入框追加一个常驻的「打开」按钮：点一下在新标签页打开，同时输入框始终可编辑。
非法链接（非 http/https）时按钮置灰 + title 提示；误点给出明确 ElMessage，
不做静默失败。两处（list.vue / buyOdoo.vue）交互一致。

★ 为什么不做「双击解锁编辑」
  1) 双击是**隐藏交互**，没有任何视觉提示，用户不会发现；
  2) 双击在输入框内与「选中文字」冲突（复制片段时会误触发）；
  3) 追加按钮零学习成本，且不牺牲可编辑性 —— 两者目标相同，代价更低。
  链接的「只看不改」需求若有，应走权限（只读渲染），而不是靠双击切换模式。
 2026-09-17 11:33:15 +08:00
yueli
938051fe29 feat(material): 采购链接前端（表单 + 列表列），并修复 Odoo 页保存后丢搜索 
一、采购链接 UI（list.vue 基础信息 / buyOdoo.vue 基础信息(Odoo)）
  各补齐 6 处：columns、permissionMap、列设置复选框、表格列、表单字段、compareFields。
  · 表格列带双重守卫（columns.X.visible && hasColPermission），无权限者整列不渲染
  · 表单字段套 hasFieldPermission('purchaseLink')，无权限者整项不显示
  · ★ compareFields 必须加：编辑走的是「差异比对后只提交变更字段」，
    漏了这一项则改了链接也不会被提交（静默失败，排查成本极高）

二、采购链接的 href 白名单
  新增 safeHref()：只放行 http/https。
  ★ 该字段由用户自由填写，直接绑到 href 上时 `javascript:` 伪协议会被浏览器
    当成可执行链接 —— 点一下就执行脚本。非法值的行显示「格式无效」而非链接。

三、修复 Odoo 页「保存后列表变空、必须重新搜索才恢复」
  根因：fetchOdooSummary() **无条件清空 groupCache**，却只在关键词变化时重置
  activeCategories。保存编辑后关键词未变 → 分组仍显示为「已展开」、缓存却空了，
  而 loadGroupItems 只由展开事件触发、不会重跑 —— 面板保持展开却无数据。
  修法：关键词未变时，清缓存后把**仍展开的分组重新拉一遍**（与文件内批量操作
  处既有的 delete + loadGroupItems 模式一致）；关键词变了才折叠全部分组。
  基础信息页（list.vue）不受影响：它的 getList 会完整带上 queryParams。
 2026-09-17 11:26:42 +08:00
yueli
6cb30a21fd feat(material): 采购链接接入读写映射与服务层 
· models/base.py：新增 purchase_link 列（text）并加入 to_dict（purchaseLink）
· field_permissions.py：读过滤映射 purchaseLink → material_list:purchaseLink
· inbound/base.py：POST 与 PUT 两处 field_to_perm 同时补入（漏掉任一处，
  新增/修改就会各缺一半）
· base_service.py：create_material 写入、update_material 按字段存在与否更新

★ 写侧刻意**显式纳入映射**而非依赖「不在映射中→默认允许」的兜底分支 ——
  那个分支正是上一轮附件备注「谁都能写」的成因，新字段不再走它。

验证（6 个角色）
    SUPER_ADMIN / SUPERVISOR / WAREHOUSE_MGR / INBOUND → 读✓ 写✓
    OUTBOUND / SALES                                   → 读✗ 写✗
  读写逐角色一致；超管走 material_list:* 通配分支、过滤整段跳过（已单独复核）。
 2026-09-17 11:26:36 +08:00
yueli
2f658407c3 feat(db): 基础信息新增「采购链接」字段并注册权限 
需求：物料主数据增加一个可直接跳转的补货地址（淘宝/1688 等），纳入字段权限管控。

★ 设计取舍：读写**共用同一个权限码** material_list:purchaseLink
  上一轮刚修完「写用 A 码、读用 B 码」造成的读写错位（附件备注），新字段刻意
  沿用 referencePrice 的既有模式 —— 一个码同时进 field_permissions.py（读过滤）
  与 base.py 的 field_to_perm（写过滤）。单码最大的好处是**结构上不可能错位**：
  能读必然能写、反之亦然，不会再有「填了看不到」或「看得到改不了」。
  若将来要求「能看不能改」，需拆两个码并同步改三处，届时一并回归验证。

★ 列类型用 text 而非 varchar(N)：外链常带很长的查询串，截断后是打不开的地址，
  且截断是静默的 —— 用户只会觉得「链接坏了」。

默认授予 SUPER_ADMIN / SUPERVISOR / WAREHOUSE_MGR / INBOUND（覆盖实际补货的人
与管理物料的人）。⚠ 这是本次取的默认值，业务可按需增删 —— 改 VALUES 再执行一次即可。

幂等；不含 psql 元命令，DataGrip 可直接整段执行；含核对段与回滚段。
 2026-09-17 11:26:36 +08:00
yueli
2f7a81ff3d fix(material): 物料列表列加双重守卫，消除「有表头无数据」的空列 
现象
----
收紧某字段读权限后，后端已把值抹成 null，但表格列照常渲染 —— 留下一列
全是「-」的空表头，白占屏幕宽度。反馈的「专业名称」即属此类。

两处前提与代码不符，先澄清
----
· 列展示设置里**已有**「专业名称」选项（list.vue:190），columns.commonName
  也**已在** columns 数组中（默认 visible: true）—— 无需补充。
  该选项与表格列都走 hasColPermission('commonName')，没有权限者看不到选项，
  与「没权限就看不见这列」的目标一致，并非缺陷。
· 真正的缺陷在同一处：**表格列只有 columns.X.visible，没有权限守卫**。
  16 个数据列里仅 isApprovalRequired 有（且用错了码）。

改动
----
一、给全部数据列补上 && hasColPermission('<key>')（两文件各 15 列；
    isApprovalRequired 原先写成 userStore.hasPermission('material_list:isApprovalRequired')，
    改为同一函数，避免复选框与表格列各用一套口径）。
二、修正 permissionMap 两处与后端读过滤的口径错位：
      isInspectionRequired: material_list:operation → material_list:isInspectionRequired
      isApprovalRequired:   material_list:operation → material_list:isApprovalRequired
    （以 app/utils/field_permissions.py 为准）

★ 为什么第 2 步是必须的：前端按 operation 判断会以为「有权限」，而后端其实
  按另一个码把字段抹成了 null —— 于是渲染出一列全是「-」的空表头。
  前端判定码必须与后端读过滤码**逐字段一致**，否则修了守卫也照样是空列。

验证
----
· 两个文件的数据列 100% 带权限守卫（grep 复核）
· 前端 permissionMap 与后端 STOCK_FIELD_RBAC_MAPPING 逐字段比对：
  16 项中 14 项完全一致；id / isEnabled 两项前端更严（后端为公开字段）——
  方向安全，不会产生空列
· 前端 vite build 通过
 2026-09-17 11:20:59 +08:00
yueli
70071e111a fix(material): 附件备注输入框按写权限置灰，消除 UI 与后端口径撕裂 
背景
----
读权限（material_list:files，6 角色）决定「产品图」整块是否显示；
但写权限已收紧到 material_list:remark_edit（3 角色）。若前端不区分，
入库员/出库员/销售会看到可输入的备注框，填完却被后端静默丢弃 ——
正是本次要消灭的「能填却存不进去」的撕裂。

改动
----
list.vue（基础信息）与 buyOdoo.vue（基础信息(Odoo)）各新增 canEditRemark，
两个备注输入框绑定 :disabled="!canEditRemark"，并把占位文案切换为
「无编辑权限，仅可查看」，避免用户对着灰框发懵。

三处口径必须一致，已交叉核对：
    前端 list.vue / buyOdoo.vue 的 canEditRemark
    后端 base.py 的 field_to_perm（写）
    后端 field_permissions.py 的映射（读）
 2026-09-17 11:07:58 +08:00
yueli
fd084bf8fd fix(material): 附件备注纳入写权限管控，废止「不在映射中→默认允许」的兜底 
问题
----
POST /inbound/base/ 与 PUT /inbound/base/<id> 的 field_to_perm 里**没有**
productImageRemark / manualLinkRemark，于是这两个字段落入
「不在映射中 → 默认允许」的兜底分支 —— 任何能调通该接口的角色都能改。
配合读侧引用幽灵权限码，形成「谁都能写、除超管没人能读」的错位。

改动
----
两处映射（创建 + 修改）同时显式补入：
    'productImageRemark': 'material_list:remark_edit',
    'manualLinkRemark':   'material_list:remark_edit',
无写权限者的请求不会携带该字段进入服务层 —— 是「丢弃本次修改」而非
「写成空值」，因此不会误清既有内容。

★ 超管不受影响：base.py 的 get_current_user_permissions() 对超管返回的
  硬编码列表以 'material_list:*' 开头，命中通配符分支后整段过滤被跳过。

验证（6 个角色 × 读写，12 项断言全通过）
    超管 / 主管 / 库管    → 读✓ 写✓
    入库 / 出库 / 销售    → 读✓ 写✗
 2026-09-17 11:07:57 +08:00
yueli
6b7b174e3d fix(db): 补注册附件备注的读写权限码（修「写通读断」的权限错位） 
根因（比上一轮报告的更深一层）
----
field_permissions.py 的读过滤要求两个权限码：
    material_list:productImageRemark / material_list:manualLinkRemark
而这两个码**在 sys_element 里根本不存在**，也从未授予任何角色 —— 是「幽灵权限」。
除 SUPER_ADMIN（走 material_list:* 通配符绕过）外，没有任何人能通过读过滤。
配合写侧的「不在映射中 → 默认允许」兜底，形成：
    谁都能写、除超管没人能读 —— 填了存进去了，回显却被抹成 null，
    看起来就是「保存不了」。

本次改动
----
一、读侧：注册这两个元素，授予与 material_list:files **完全相同的 6 个角色**
    （INBOUND / OUTBOUND / SALES / SUPERVISOR / WAREHOUSE_MGR / SUPER_ADMIN）
    依据：备注依附于图片，「能看图的人就应该能看备注」。
二、写侧：新建 material_list:remark_edit，只授予 3 个核心管理角色
    （SUPER_ADMIN / SUPERVISOR / WAREHOUSE_MGR）。
    ★ 为何不复用 material_list:operation：它授予了 5 个角色（含 INBOUND /
      OUTBOUND），比业务要求的 3 个更宽，达不到「只有核心管理角色可改」。
    ⚠ 该码只做精确匹配，**切勿用 @permission_required 包裹** ——
      _expand_operation_perms 会前缀桥接，把 material_list:operation 的持有者
      一并放行，等于把刚收紧的口子又捅开。已在迁移与代码注释中双处警示。

幂等，可重复执行；脚本文本不含 psql 元命令，DataGrip 可直接整段执行。
 2026-09-17 11:07:50 +08:00
yueli
b26b124f8b chore(db): 部署脚本改用通用 SQL 核对段，兼容 DataGrip 
psql 的 \echo 是元命令，DataGrip / DBeaver 不认，整份执行会直接报语法错误。
核对段改用 SELECT '常量' AS "核对项" 输出标签行，任何客户端都能跑
（psql 下效果相同）。同步修正头部说明中「需用 psql」的过期表述。

已在临时库重跑验证：零报错、核对结果与改前一致、重跑幂等。
 2026-09-17 10:51:31 +08:00
yueli
d6234622e8 chore(db): 借库转交完整部署脚本（生产可执行） 
把本轮 6 个迁移（phase4 / 4b / 4c / 4d / 4e / 4f）按依赖顺序合并为一份
可直接在生产执行的脚本，并在一个模拟「部署前状态」的临时库上完整验证。

内容
----
 1. trans_borrow 补 4 列（borrower_id / current_holder_id /
    current_holder_name / dispatch_operator）+ 2 索引
 2. trans_borrow_transfer 建表（最终形态）+ 7 索引
 3. trans_borrow_return 建表 + 3 索引
 4. 回填 trans_borrow 身份锚点（仅唯一命中者，重名/无法映射留 NULL）
 5. 回填遗留转交流水的 borrow_no 与状态
 6. 回填 reject_seen_at（存量拒收标记为已告知）
 7. 从 remark 拆出被拼接的 reject_reason
 8.（注释掉）borrow_transfer 权限码 —— 已无代码引用，默认不建
+ 执行后核对段 + 回滚段

★ 验证中发现并修掉两个真实缺陷（都不是「看起来能跑」能暴露的）
  1) 顺序缺陷：第 5 段原先把遗留流水**一律**标成 ACCEPTED，导致第 6/7 段
     按 status='REJECTED' 找行时一条都匹配不到（旧结构表里 status 是刚加的
     列、全是默认 PENDING）。真正的信号在备注的 '[拒绝原因]' 标记里，
     现据此还原真实状态。
  2) 孤儿流水：第 5 段按 borrow_id 关联，来源借用行已被删除的流水匹配不上，
     会永久停在 PENDING —— 在接收人那里变成谁也处理不掉的幽灵待办。
     已加兜底把「没有单号」的遗留行一律结掉。

★ 两处 ⚠ 警示已写入脚本：第 5/6/7 段设计为**新代码上线前执行一次**；
  若在功能已投产后重跑，会把当时真实的待接收/待告知记录误标。

验证方式：建临时库复刻部署前结构（旧 trans_borrow + 旧结构转交流水表 +
重名/无法映射/已归还/孤儿等边界数据），执行脚本后核对：DDL 与索引齐全、
身份锚点按唯一性正确回填、遗留流水状态从备注还原、原因正确拆出、
孤儿流水被结掉、无报错；再执行第二遍确认幂等（结果完全一致）。
 2026-09-17 10:49:34 +08:00
yueli
1ebd06e68c style(borrow): 时间线转交节点去掉冗余的「发起人」 
转交已收紧为「仅当前持有人本人可发起」，发起人恒等于该节点已显示的 from_name
（「A → B」）—— 同一人出现两次是纯冗余，且第二次还是完整 username 格式
（杜邢宸/duxingchen），与全站展示名口径不一致。去掉。

数据不受影响：operator_name 仍在流水里存档，仅不再展示 —— 审计追溯仍可查。

归还 / 报废节点的「经手库管」保持不变：那里确实存在独立的窗口经手人
（归还人是 returner_id，经手库管是 operator_name），措辞正确。
 2026-09-17 10:47:25 +08:00
yueli
b5f96384e9 style(borrow): 流转时间线区分成败 —— 被拒转交红点 + 红标签 + 原因独立成行 
问题（截图反馈）
----
被拒收的转交和正常转交一样是黄色节点、黄色「转交」标签，拒绝原因又粗暴地
拼在备注后面（「备注: 3333 [拒绝原因] 5555」）—— 完全看不出资产交接失败。

改动
----
一、节点颜色：被拒收的转交 el-timeline-item 的 type 设为 danger（红色圆点）；
    待接收（PENDING）保持 warning（进行中，不是失败）；
    其余沿用动作类型配色。
二、动作标签：被拒的显示红色「转交被拒」，不再显示黄色「转交」。
三、原因分行：转交备注灰色单独一行，拒收原因另起一行、红色加粗前缀，
    彻底解决文字挤在一起的问题。

顺带修正标签措辞
----
「经手库管」改为「发起人」：转交已收紧为「仅当前持有人本人可发起」，
该字段存的就是发起人本人，标成库管是错的。
（归还节点的「经手库管」保持不变 —— 那里确实是独立的窗口经手人。）

★ 一个可议之处：转交节点现在会同时显示「A → B」和「· 发起人：A」，
  同一个人出现两次（字段格式不同：一个展示名、一个完整 username）。
  若觉得冗余，可去掉后者 —— 但那属于展示取舍，未擅自决定。
 2026-09-17 10:46:32 +08:00
yueli
681607bd43 feat(borrow): 拒收原因独立成列，与转交备注彻底分离 
背景
----
拒收原因此前是**拼进 remark** 的：
    transfer.remark = f"{remark}\n[拒绝原因] {reason}"
前端拿到的是「3333\n[拒绝原因] 5555」这样一坨，时间线上两句挤在一起，
无法分辨哪句是发起备注、哪句是对方拒收的原因。

改动
----
· trans_borrow_transfer 新增 reject_reason text 列；
  reject_transfer 改为写入该列，不再拼进 remark。
· 存量按 '[拒绝原因] ' 标记切分回填（实测仅 #22：
  remark 3333 / reject_reason 5555）。
· 时间线事件带出 reject_reason，前端才能分行展示。

★ 为什么拆列而不是让前端解析字符串
  1) 拼接格式是隐式契约：改分隔符或加前缀，前端解析就静默失效且难排查；
  2) 用户完全可能在备注里自己打出 '[拒绝原因]' 字样，按标记切分必然误判 ——
     已加测试用例锁定该场景；
  3) 结构化字段才能参与查询与统计（如按拒收原因归类）。
  存储层能表达的东西，不该靠字符串约定去还原。

★ 一个迁移期踩到的坑：btrim 默认只去空格、不去换行。
  拼接留下的是 '3333\n'，只写 btrim(x) 会残留换行；必须显式给出字符集
  btrim(x, E' \t\r\n')。已修正脚本并对存量做了一次清理。

验证（7 项断言全通过）
  备注不被污染、原因写独立列、无原因时为 None、
  用户备注含同名标记也不误判、库存零副作用、数据零残留。
 2026-09-17 10:46:31 +08:00
yueli
f4f887c2b4 feat(borrow): 全局提醒支持双向 —— 发起方也能收到「转交被拒绝」 
提醒组件从单向（待我接收）扩展为双向，一次轮询同时取回两类：

  ① 转交被拒绝 —— 我发起、对方拒收，物品责任仍在我手上
  ② 待我接收   —— 别人转给我、等我确认

弹窗（沿用中央 Modal + 遮罩，不进则已、进则打断）：
  标题「转交被拒绝」，列出被拒物品（物料名 + 单号 + 接收人，超过 5 笔折叠计数），
  按钮【去处理】(跳借还记录) /【知道了】。

★ 优先级：拒绝提醒优先于待接收提醒，且**一次只弹一个弹窗**。
  前者是「责任已回到你手上」的状态变更，后者是「等你确认」的待办；
  本次弹了拒绝就直接 return，待接收那条留给下一轮（此时拒绝已 ack），
  避免两个 Modal 叠加打扰。

★ 两条退出路径都算「已知悉」并 ack —— 否则每次登录都会再弹同一条，
  从提醒退化成骚扰。ack 失败不阻断，下一轮还会再提醒（宁可多提醒一次，
  也不能漏）。

防叠加沿用上一轮的模块标志 + DOM 探测，标题白名单扩为两个。

顺带：流转明细时间线为转交节点补状态标签（已拒绝/待接收），被拒的转交
不再与成功的长得一模一样。

验证（node 复刻判定链）
  既有拒绝、又有 2 件待接收 → 弹[转交被拒绝]；确认后 ack；
  下一轮 → 弹[待办通知] count=2；再轮询 → 不弹(未变)。
  拒绝优先、不叠加、ack 后待接收提醒正常补上。
 2026-09-17 10:44:07 +08:00
yueli
f24797ff1f feat(borrow): 拒收须告知发起方（责任回到他手上，不能静默） 
背景
----
双向握手补上了「接收人确认」，却只做了单向告知：接收人能看到待办，发起方却
对结果一无所知。**被拒绝时物品责任仍在发起方手上** —— 他若不主动查列表，
就会误以为已经交接出去，责任链出现静默断点。

（ACCEPTED 不需要告知：东西已经交出去了，发起方无需动作。）

改动
----
· trans_borrow_transfer 新增 reject_seen_at（NULL 且 REJECTED = 尚未告知）。
  ★ 为什么需要持久标记而不是前端去重：换台电脑、换个浏览器就会重新提醒；
    而这条信息的分量（责任归属）值得一个持久标记。
  ★ 存量已拒绝的流水一律标记为已告知：它们产生于本功能上线之前，
    追溯提醒只会打扰（实测仅 1 条：#22，验收时的测试数据）。
· get_unseen_rejects(user_id)：返回「我发起、被拒、尚未告知我」的转交，
  并批量解析物料名 —— 只说「某笔转交被拒」发起方仍不知是哪件东西还在
  自己手上，必须让他一眼认出来。
· ack_rejects(user_id, ids)：发起方确认后写 reject_seen_at，幂等。
· GET .../transfer/pending-count 的响应并入 rejects：与待接收数量共用同一次
  轮询，前端不必多打一个请求。
· POST .../transfer/reject-ack：无 permission_required，同 accept/reject。

顺带补一处同源显示缺口
----
流转时间线里，被拒绝的转交与成功的长得一模一样 —— 发起方翻记录时同样会
误判。现将转交状态一并带出时间线事件。

验证（15 项断言全通过）
----
发起方收到待告知的拒绝（含物料名/接收人/拒绝原因）；接收人与无关人看不到；
ack 后不再提醒且幂等；ACCEPTED 不产生告知；None/非法 user_id 均安全返回；
库存零副作用、数据零残留。
 2026-09-17 10:44:00 +08:00
yueli
b53e22f536 style(borrow): 待办提醒改为中央强弹窗（Modal + 遮罩） 
背景
----
右上角 ElNotification 在仓库作业现场视觉提示太弱，极易被操作员忽略，
待接收的物品就一直在系统里悬着。

改动
----
ElNotification -> ElMessageBox.confirm：
· 屏幕正中 + 灰色半透明遮罩，强制打断注意力；
· 标题「待办通知：借库转交」，内容「您有 X 件物品等待接收确认，请及时处理。」；
· 按钮【去处理】/【稍后处理】；前者 router.push('/operation/records')，
  后者仅收起弹窗，不阻断当前工作；
· closeOnClickModal=false（点遮罩不关，避免误触即消失），
  但保留 showClose 与 Esc —— 强提醒不等于关不掉，用户始终有明确退出路径。

★ 防叠加（两道，模块级标志 + DOM 探测）
  reminderOpen 用**模块级**变量而非组件级：即便组件被重复挂载
  （HMR、多 Layout 实例）也能保证同一时刻只有一个提醒弹窗。
  另按标题探测屏幕上是否已有同名弹窗，覆盖标志失效的极端情况。

★ 一处必须修正的时序隐患：记录时机
  原逻辑是「先写 sessionStorage 已提醒数量，再弹窗」。加了并发防护后，
  弹窗可能被跳过（已有弹窗在屏），而数量却已记下 —— 数量不变 → 下次不再弹，
  **这条提醒被永久吞掉**。
  现改为「先弹，弹成功了才记账」：showReminder() 返回是否真的弹出，
  没弹出就不记账，留给下一轮轮询重试。

验证（node 复刻判定链，全场景通过）
  3 → 弹；仍 3 → 不弹；弹窗开着时变 4 → 不弹且不记账 →
  收起后轮询 4 → 弹；归零 → 清记录；新来 2 → 弹。
  弹窗序列 [3,4,2]，无重复、无叠加；同一轮内并发两次 check 只弹一次。
 2026-09-17 10:40:00 +08:00
yueli
c566d1b728 style(borrow): 借还记录表格响应式改造，消除横向滚动与操作列不可达 
背景
----
主表共 11 列，原先除 2 列外用 width 硬编码，最小总宽约 1528px；
1440 笔记本可用宽度只有约 1240px（屏幕 - 180 侧边栏 - 20 内边距），
必然撑出横向滚动条，操作按钮被推出屏幕，用户得拖滚动条才能点转交。

一、固定操作列
----
主表操作列原本已有 fixed="right"；**明细表的操作列没有**，本次补上。
子表嵌在主表展开区内，容器更窄（两侧各留 40px），不固定更容易被挤出屏幕。
操作列宽度 250 -> 230（实际按钮最多 3 个并存，230 足够）。

二、弹性列宽
----
按「内容长度是否确定」划界：
  用 min-width（可伸缩）—— 单号 150 / 借用人 90 / 当前持有人 120 /
                            归还人 90 / 归还时间·预计 200
  用 width（定长）    —— 借出时间 160 / 借出物品 80 / 状态 110 /
                            电子签名 100（原 140，两个小标签用不了那么宽）
  展开列本身约 48px，不可控
明细表同步：SKU 120 -> min-width 110；当前持有人 130 -> min-width 120。

主表最小总宽由约 1528px 降到 1378px。

三、长文本省略
----
物料名称、SKU、单号均已带 show-overflow-tooltip —— 超长物料名自动省略号，
悬浮显示全称，不会因单条数据撑爆整表。

★ 如实说明：11 列的表格在 1600px 以上屏幕可完整铺开；1440/1366 笔记本上
  仍会保留一条横向滚动条（最小 1378px vs 可用约 1240px），这是列数决定的，
  不删列就无法根除。但操作列两级都已吸附最右侧，**用户不再需要滚动即可操作** ——
  这正是本次要解决的核心痛点。若要做到零滚动条，需另议「窄屏隐藏次要列
  （电子签名/借出物品）」或侧边栏可折叠。
 2026-09-17 10:35:11 +08:00
yueli
2c732a9a3a feat(borrow): 全局待办强提醒（接收人不再处于盲区） 
新增无渲染组件 PendingTransferNotifier，挂在 Layout（路由切换常驻、且只在
已登录区域渲染，天然保证「有 token 才查」）。

UI
----
ElNotification，type=warning、duration=0（不自动关闭，须用户处理或手动点掉）：
  标题：待办通知：借库转交
  内容：您有 X 件物品等待接收确认，请及时处理。【去处理 >】
点击【去处理】关闭通知并 router.push('/operation/records')（借还记录页）。
message 用 VNode 构造而非 dangerouslyUseHTMLString —— 不必把数量拼进 HTML 字符串。

防骚扰（两道）
----
· 会话级去重：sessionStorage 记「上次已提醒过的数量」，只有数量**变化**才再弹。
  用 sessionStorage 而非 Pinia —— 前者跨刷新存活，后者会重置，刷新即轰炸。
· 数量归零时清掉记录，下次新转交能重新提醒。

★ 加了 2 分钟低频轮询（超出需求所写，但需求目标需要它）：
  需求只要求「初始化时查一次」，而 SPA 只在首次进入时初始化 —— 已打开页面的
  用户永远收不到提醒，与「第一时间响应」的目标相悖。有去重逻辑兜底，
  轮询不会造成重复打扰。不需要的话删掉定时器即可。

错误一律静默：提醒是锦上添花，不能因接口抖动弹错误框刷屏。

验证：去重状态机用 node 复刻验证 —— 3→2→1 各弹一次，刷新与轮询均不重复，
归零后再来新转交能重新提醒。
 2026-09-17 10:30:13 +08:00