KCGL/v1 at 077fd2f2cfe1514144f3444bb9f63e8b10eea11d - KCGL

Files

yueli 077fd2f2cf feat(borrow,scrap): 补齐申请人撤回端点，与出库对齐

背景
----
出库已有独立的申请人撤回端点（仅 @jwt_required + 服务层归属断言），
但借库/报废没有：

  · 借库撤回复用 close 端点，权限是 op_borrow_approval（管理路径），
    普通员工调用返回 403；
  · 报废撤回带 @permission_required('scrap_apply')，同样挡住普通申请人
    （scrap_apply 只授予 INBOUND/OUTBOUND/SUPERVISOR/SUPER_ADMIN）。

结果是「我的申请单」页面里，借库/报废的撤回按钮对普通员工点了报错。

借库
----
服务层拆成与管理路径并列的两条入口（与出库同构）：

  mark_completed     —— 管理路径，需 op_borrow_approval，仅 status==1
  withdraw_request   —— 申请人路径，仅校验单据归属，status 0 或 1

两者共用 _release_and_close()，释放逻辑只有一份实现。
新增 POST /transactions/borrow/request/<id>/withdraw（仅 @jwt_required）。

报废
----
withdraw() 增加 require_owner 参数区分两条路径：
  require_owner=True （默认，申请人路径）→ 断言 applicant_id == operator_id
  require_owner=False（管理路径）        → 由调用方权限装饰器鉴权
WITHDRAWABLE_STATUS 从 (1,) 放宽到 (0, 1)，与出库/借库对齐。
移除端点上的 @permission_required('scrap_apply')，改走归属校验。

安全实测
--------
  借库 B 撤 A 的单 → 403，库存仍是 27（未被释放）
  借库 A 撤自己的单 → 200，30 完全释放
  报废 B 撤 A 的单 → 403
  报废 A 撤自己的单 → 200
  主管代撤员工的单（特权路径）→ 200

2026-09-10 15:46:55 +08:00

common

feat: 首页全局搜索支持按 SKU 查库位——采购/半成品/成品库存纳入搜索并显示库位

2026-09-07 15:47:25 +08:00

export

feat: 实现异步导出骨架（Threading + Redis 状态流转），支持 POST 提交/轮询状态/下载文件

2026-05-19 10:35:33 +08:00

inbound

refactor(audit): 审计架构清理——复活白名单监听器、停用噪声监听器、清除僵尸装饰器

2026-09-10 14:16:27 +08:00

scan

4.29扫码获取库位小工具接口