b67d577616
动机 ---- 出库/借库/报废三个模块各有一套审批流，申请人此前没有统一入口。 新增只读聚合视图，把三类单据合并返回。 为什么单独建蓝图 ---------------- 权限模型不同：审批端点是「管理视角」，本端点是「申请人视角」。 把两者塞进同一端点（if not privileged: applicant_id = me）会让管理逻辑 与用户逻辑混流，一旦 is_privileged_viewer() 判定出错即越权。 本模块从设计上就没有「看别人」的分支 —— applicant_id 硬编码为当前用户。 只读保证 -------- 本模块只做查询，不修改任何数据。撤回等写操作仍由各模块自己的端点承担 （因为三者释放逻辑不同：出库/借库已接入预占，报废尚未接入）。 把风险锁在只读层，即使聚合逻辑有 bug 也不会破坏业务数据。 字段归一化 ---------- 三个模块的 items_json 存在差异，统一在服务端抹平： · 数量字段：报废用 scrap_qty，出库/借库用 quantity → 统一为 quantity · 库位字段：报废用 location → 统一为 warehouse_location 这专门避免「报废行的数量列显示空白」这类不报错的隐性 bug。 健壮性 ------ 单个模块查询失败时记日志并跳过，其余模块照常返回 （例如某张表尚未迁移时，其它两类仍可用）。 响应中附带 withdraw_endpoint 字段，前端据此分发撤回请求， 无需硬编码三个模块的 URL 映射。 实测 ---- 普通员工（INBOUND 角色，无任何审批权限）访问 → 200，18 单 三类单据齐全，type_label 正确 报废明细数量字段归一化成功（quantity=1.0） B 看不到 A 的单 → 0 条 type=scrap 过滤 → 全部为报废