|
|
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 |
|
|
|
69c38a1bf7
|
feat(return): 逆向物流数据模型与迁移
新增原单退回与不良品在管的持久化结构。
- TransOutbound 增 returned_quantity（numeric(19,4)，非 float）：该值参与
「return_qty <= quantity - returned_quantity」判等，浮点误差会让反复部分
退回后出现「已退满却判定未退满」的错判
- 新增 TransReturn：退回流水，每次退回写一条而非覆盖式更新。刻意与
trans_borrow 划清界限——后者部分归还时会覆盖 return_time/operator，
导致归还历史永久丢失
- 新增 TransDefectiveGoods：不良品在管台账。坏件全程不入库存表，因为
status 是行级属性而质量是件级属性，把坏件加回原行只能整行打不良
（实测 stock_buy 单行最大 4789 件、中位 8 件，整行打不良会凭空损失良品）
- 状态机：待处理 → 处理中 → {已回库|已报废|已闭环}。终态由累计去向推导
而非「最后一次动作」——一批坏件可能既回库过又报废过，按最后动作定状态
会产生误导
- restocked_qty/scrapped_qty 两列：二期用 quantity-remaining_qty 反推回库量，
三期加入报废出口后该反推失效
- 审计白名单与模型预加载同步登记（监听器绑定 18 → 20 个模型）
迁移脚本均为纯追加式 DDL，含预检、回滚段与执行后核对。首个脚本用
COALESCE 包裹数量列——库存表允许数量为 NULL，而「NULL 大于 0」求值为
NULL 而非真，裸写会让脏行在预览与诊断两次查询里凭空消失。
|
2026-09-16 15:45:22 +08:00 |
|
|
|
4808a48594
|
refactor(audit): 审计架构清理——复活白名单监听器、停用噪声监听器、清除僵尸装饰器
一、统一为单一监听器实现
原先两套 SQLAlchemy 事件监听器并存：
· app/utils/audit_events.py —— 全局监听 db.Model、无白名单、无请求上下文守卫（实际在跑）
· app/core/audit_listener.py —— 白名单制、有守卫、有模型级开关（从未生效）
后者失效的根因：注册代码写在 extensions.py 的 init_extensions() 内，
而该函数全仓库只有定义、没有任何调用（create_app 直接内联调用 db.init_app 等）。
现统一由 app/core/audit_listener.py 承担，并在 create_app() 中显式注册。
extensions.py 的死函数 init_extensions 整体删除，避免后人误以为它是有效入口。
二、修复监听器三处致命缺陷（此前注册了也写不进数据）
1. 事件回调第二个参数是 Connection，原代码却调用 Connection.add()（不存在），
每次写日志都抛 AttributeError 并被 except 吞掉 → 改为 connection.execute()
2. register_audit_listeners 从 app.models 批量 import 多个未导出的模型，
ImportError 被上层 try/except 吞掉 → 改为按表名从 db.metadata 取模型
3. 本项目有 31 处函数体内延迟导入模型（如 scrap.py 内部才 import ScrapApproval），
一次性注册会静默漏表 → 增加 ensure_audit_listeners() 惰性补绑，
并在模型预加载段补全审批单/BOM/采购等模型
三、强约束
· WHITELIST_TABLES：仅 18 张核心业务表，系统表/草稿表/向量表不再自审
· has_request_context() 守卫：系统初始化与后台定时任务不再产生 username=system 噪声
· IGNORE_FIELDS 增加 password/password_hash/salt/token/secret/api_key（安全红线）
· created_at 显式写 beijing_time()，与全系统时间口径一致
四、清除僵尸装饰器
@audit_log 早已退化为直接透传的空壳（module/action 参数全被忽略，
数据库中零星的中文 action 即其历史遗留产物），却仍挂在 38 处路由上。
连同 13 个文件的 import 一并移除；audit_events.register_audit_events 改为空操作。
验证：应用上下文中的写操作不产生日志；HTTP 请求产生 5 条日志，
对象为业务单号（APR-SCRAP-... / SKU），模块中文，操作人真实，时间为北京时间。
|
2026-09-10 14:16:27 +08:00 |
|
|
|
567c3175f6
|
fix: 审计日志跳过向量字段，修复 numpy 数组比较异常；补全三大入库单更新向量提取，统一删除确认弹窗
|
2026-05-25 11:11:10 +08:00 |
|
|
|
2a6e3979e8
|
fix: 审计监听器在非 HTTP 上下文的初始化操作（如 PermissionService）中直接跳过，避免产生大量 system 用户日志
|
2026-05-19 10:58:22 +08:00 |
|
|
|
f8f5b05d7d
|
refactor(audit): 废弃装饰器+分离架构，改为监听器单体直写入库
|
2026-04-20 16:04:01 +08:00 |
|
|
|
decb7f5e1f
|
debug(audit): 添加X光调试-追踪断点
|
2026-04-20 15:01:20 +08:00 |
|
|
|
1c8def7e6f
|
refactor(audit): 分离架构-监听器计算装饰器入库
|
2026-04-20 14:41:40 +08:00 |
|
|
|
381d1fa675
|
feat(audit): 平滑升级-监听器+装饰器共存，装饰器自动检测并跳过已处理日志
|
2026-04-20 13:15:25 +08:00 |
|
