KCGL/v1 at 681607bd43067c714d9749c15fc9cb773abed124 - KCGL

Files

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

common

fix(image-search): 成品库存回填误取 batch_number，导致以图搜图必 500

2026-09-11 11:44:31 +08:00

export

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

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

inbound

feat(scrap): 报废全链路收口到审批流

2026-09-16 17:14:17 +08:00

scan

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