KCGL/services at 50232bb58f2ffb3db5a7f7e6686adbac125e9283 - KCGL

Files

yueli 0b87a72a41 feat(audit): 级联操作聚合 —— 一次业务点击只产生一条审计

问题：BOM 归档/启停这类接口一次请求改动整组数据，ORM 监听器逐行写审计，
审计页被刷屏。**实测问题范围远大于 BOM**（同一秒、同接口、同操作人的条数）：

    /api/v1/inbound/stock/draft/start-new             924 条
    /api/v1/inbound/stock/stocktake/generate-missing  898 条
    /api/v1/permissions/assign                        381 条
    /api/v1/outbound                                  110 条
    /api/v1/bom/save                                   83 条
    /api/v1/bom/archive                                58 条

全库共 311 次「单请求 ≥20 条」的突发，累计 4 万余行。

实现：URL 白名单 + 同事务合并（方案 A 的收敛版）
  · AGGREGATE_PATH_MARKERS 按**路径段前缀**匹配（不是子串）：
    /api/v1/bom_draft_x 不会命中 bom，/api/v1/somebom/thing 也不会。
  · 命中白名单的变更在 flush 期间累加到 session.info，由 Session
    after_flush 钩子合并成**一条** AuditLog。
  · details = 各行的**深度公共子集** + aggregate{count, targets}。

★ 为什么用白名单而不是全局默认合并：合并会改变审计的**语义粒度**
  （日报里「修改 354 条」可能变成几十条），全局改会让业务方以为日志坏了。
  白名单的失败模式也更安全 —— 新接口忘了登记只是"仍然刷屏"，
  而不会把两个不相干的业务动作错误合并（错误合并 = 把 A 的改动记到 B 头上，
  是审计里最危险的一类错）。

★ 只取公共子集，不用某一行的值代表整批 —— 那是编造。BOM 的级联批次各行
  改动完全一致（实测 /bom/archive 400 条只有 3 种签名、349 条同一个），
  故合并**无损**；各行不一致时 changes 只留共同字段，其余由 targets 交代
  "动过哪些对象"。

★★ 钩子必须挂 after_flush，不能挂 before_commit —— 踩过的坑：
   Session.commit() 的顺序是 before_commit → flush → after_flush → COMMIT，
   而累加发生在 flush **期间**。挂 before_commit 时钩子跑在累加之前，
   缓冲还是空的；等 flush 填满后没人再写 —— 结果是**审计整批丢失**
   （实测归档请求产出 0 条日志，业务却已提交，正是最危险的"改了但没记录"）。
   首版就是这个错，靠真实请求打 /bom/archive 数日志条数才抓出来。

★ 为什么不用 after_request/teardown：那跑在业务事务之外，业务回滚也会留下
  一条"成功"的审计 —— 假账。after_flush 仍属同一事务，聚合日志与业务改动
  同生共死（实测回滚后不留日志）。

消费端：
  · changes_summary 优先识别 aggregate，读作
    「批量更新 58 条；是否启用：是→否；是否归档：否→是（来源：/bom/archive）」
  · SNAPSHOT_VIEWS 增加 aggregate，抽屉据此渲染「变更次数 + 受影响对象表」
  · 前端把「变更对比」与「快照/汇总」从二选一改为各自独立渲染 ——
    聚合日志两者都有，原先的 v-else 会让汇总块显示不出来

验证（26 + 18 项断言全过）：
  · 真实请求 POST /api/v1/bom/archive 打一个 58 行的 BOM：
    归档前 0 条 → 归档后**恰好 1 条**，count=58、targets 58 条、
    共同变更无损、业务改动同时生效（58/58 行已归档）
  · 回滚后不留下聚合日志（59996 → 59996）
  · 路径匹配 15 个边界（含 bom_draft_x / somebom 两个反向用例）
  · 非白名单接口行为不变；日报附件 490.5K/193.4K/92.3K 与 6 列结构未变；
    导出口径与列表一致；权限与凭据过滤未松动；字典 181 键零缺失
  · vue-tsc 与 vite build exit=0

⚠️ 仅对**改动之后**的请求生效，历史 4 万行突发数据不变。
⚠️ 验证过程在库里留下 4 条真实审计记录（id 60278/60279 等，均是本人对
   SF-9000-9 V2.2 的归档/取消归档操作，业务数据已精确还原为原状）。
   审计记录未删除 —— 删审计要单独决策。

2026-09-28 11:07:10 +08:00

export_service

feat: 添加以图搜图功能（CLIP ONNX + pgvector）+ Dify会话修复 + 版本升至V3.30

2026-05-21 14:09:57 +08:00

inbound

fix(inbound): 按单入库时从采购申请单补回成本价

2026-09-22 14:09:08 +08:00

修复服务器端打印字体丢失问题，修复上传脚本打包过大问题

2026-05-27 09:57:01 +08:00

__init__.py

…

approval_control.py