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
..
2026-09-17 12:01:11 +08:00
2026-05-22 10:59:39 +08:00
2026-01-27 15:50:23 +08:00
2026-09-02 18:39:09 +08:00
2026-01-26 13:47:53 +08:00
2026-09-01 13:52:56 +08:00
2026-09-02 18:39:09 +08:00
2026-03-19 09:49:21 +08:00
2026-07-14 17:02:07 +08:00
2026-01-27 15:50:23 +08:00
2026-03-19 09:49:21 +08:00
2026-07-15 11:11:40 +08:00
2026-09-02 18:39:17 +08:00
2026-05-12 15:17:42 +08:00
2026-02-02 15:06:20 +08:00
2026-03-19 09:49:21 +08:00
2026-04-02 10:31:53 +08:00