duxingchen/KCGL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,115 Commits 5 Branches 0 Tags
52a3c4079cdafac28ac2b29d03926a3c52a5abf4
Commit Graph

61 Commits

Author SHA1 Message Date
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
yueli
956d4acb5f feat(audit): 快照嵌套分层渲染 + 凭据字段从接口剥离（安全修复） 
起因：借库管理等单据的详情页仍显示原始 JSON 代码块。
根因：details 有**第三种**存法 {'payload': {...}}，且内部嵌着对象数组
（items 明细行），而旧实现只认平铺的 created/deleted_snapshot，
遇到非平铺结构就退化成原始 JSON。

1. 快照键收敛（后端）
   created / deleted_snapshot / payload 三种键与展示标题收进
   audit_labels.SNAPSHOT_VIEWS，经 /audit/labels 下发 snapshotViews，
   前端不再硬编键名 —— 将来加第四种只改一处。
   audit_export_service 与 daily_report_service 改为引用同一份。
   changes_summary 也改用 snapshot_of_any：payload 型记录的新增摘要
   此前整列为空，现在有内容了（如「新增（借库管理）：物料明细 1 项、
   备注、借用人、签名、预计归还时间」）。

2. 分层渲染（前端）
   · 标量字段 → el-descriptions（保留字典翻译与空值/技术字段过滤）
   · 数组字段 → el-table：列取**所有元素键的并集**（同一数组内元素键
     并不完全一致，只取首个元素会漏字段），跳过技术字段，列头走 fieldLabel
   · 标量数组（arrival_photo 等图片 URL 列表）→ 单列表格
   · details / payload 本身是数组或标量的情况也一并处理
   · 只有确实无可识别结构时才回落到原始 JSON

   实测全库 58728 条：**0 条**会退化到原始 JSON 兜底
   （payload 1495 条全部拆出结构）。

3. ★ 安全修复：审计快照里存有**明文密码**，本次从所有出口剥离
   实测 `用户管理/新增` 的 payload 快照记着哈希前的原始密码（27 条，
   形如 '123456'、'shili0823'），因为写入路径把请求体整包记进了审计。

   · sanitize_details()：递归剥掉凭据类字段，应用于列表与详情接口
   · changes_of / snapshot_of 在**源头**滤掉凭据：逐个出口去补必然漏掉
     某一个，而漏掉的那个就是泄漏点（日报附件、导出、摘要都走这两个函数）
   · 凭据判定用**关键词**（password/passwd/secret/token/private_key）
     而非逐个登记 —— 今天漏的是 payload 里的 password，明天可能是
     reset_token。新表加凭据字段也自动被挡住。

   ★ 第一版我只做了前端隐藏（hiddenFields），被测试抓出来：原始响应里
     密码照样在，打开 devtools 就读得到。**要挡的数据必须在接口出口剥掉，
     前端隐藏不是防线。**

验证：14 + 15 项断言全过，含「列表/详情响应无密码原文与 password 键」
「全量导出的表头与单元格均无凭据」「日报三天附件无凭据」
「sanitize_details 递归进嵌套数组且不原地改原对象」。
6 列结构与附件大小未变（490.5K / 193.4K / 10.3K）；vue-tsc 与 vite build exit=0。

⚠️ 数据库中仍存有明文密码（16 条非空），本次只挡展示与导出，**未改数据** ——
   改数据不可逆，需单独立项决定。
 2026-09-28 10:40:00 +08:00
yueli
46aec0b954 feat(audit): 提升可读性 —— 操作对象补全物料名、详情降噪、字段字典补齐 
业务方反馈两点：操作对象太干瘪、详情快照噪音太多。

1. 操作对象补全为「SKU - 物料名称 (规格型号)」

   库里 target_name 大多只存了 SKU（'0000002270'），入库类甚至存的是内部
   标识（'stock_buy ID:1667'），业务人员完全看不懂。

   补全走两条路径，**正确性优先**：
     · 快照里的 base_id（CREATE/DELETE 的库存行）—— 权威，零歧义
     · target_id 唯一命中一张股票表 —— 实测与上一条 1230/1230 完全一致

   ★ 撞号一律放弃：target_id 同时命中 2 张股票表时解出的 base_id
     24/27 是错的、命中 3 张时 44/44 全错。补一个**错的**物料名比不补更糟 ——
     那是"看起来完全可信的错误答案"，业务方会照着它去找不相干的物料。
     实测 300 条撞号行 0 条被补，300 条唯一命中行全部补上。

   target_name 原值保留（target_keyword 搜索仍按它匹配），新增 target_display
   供展示。前端去掉灰显的 #target_id —— 业务人员不需要看数据库主键。

2. 详情快照降噪

   · 前端过滤空值：null / '' / [] / {} / '-'。判据**严格**：false 和 0
     不算空（`is_returned: false`、`quantity: 0` 是明确的业务事实，
     用真值判断会把它们一起吃掉，那是在篡改数据）。
   · 过滤纯技术字段：id / created_at / updated_at / target_id / module_name
     及 pgvector 的 `*embedding`（单条可达数 KB）。清单由后端下发
     （labels.hiddenFields），前端不硬编 —— 它会随新表增长，再存一份必然漂移。
     embedding 类按后缀拦截，新表加向量列不必改代码。
   · 变更对比表过滤「等于没改」的行（null ↔ 空串）。

3. 字段字典补齐：168 项

   实测快照里出现过但字典没有的字段全部补上（buyer_email / currency /
   in_date / exchange_rate / dosage / loss_rate / child / parent /
   production_* / return_* / *_threshold 等 60+ 个）。
   现在快照字段缺中文名的数量为 **0** —— 详情页不会再裸露英文。

4. 摘要优化

   · changes_of 丢掉无意义变更（null ↔ 空串）。库里 98 条记录带这种变更，
     写进摘要就是「备注：空→空」，纯噪音还挤占截断长度。
   · CREATE/DELETE 摘要改为核心属性**按槽位取值**：
         新增（入库）：入库数量 10 件、库位 ZZTEST
     而不是「新增：SKU、base、状态… 等 29 个字段」。
   · 槽位只有数量与位置两个，**不含物料** —— 物料由「操作对象」列承担，
     同一屏里再来一遍是重复。数量字段也按槽位只取一个：
     in_quantity / stock_quantity / available_quantity 值往往相同，
     取三个会得到三个一样的数字。
   · 数字去掉无意义的 .0（10.0 → 10）；单位取自物料主数据，
     纯数字的占位单位（库里有一批 unit='1'）丢弃。

验证：33 + 16 项断言全过，含「补全的物料与快照 base_id 零冲突」「撞号行
一律不补」「快照字段缺中文名 0 个」「摘要无空→空」「导出口径与列表一致」；
vue-tsc --noEmit 与 vite build 均 exit=0。
日报回归：三天附件 490.5K / 193.4K / 10.3K，6 列结构未变。
 2026-09-28 10:19:58 +08:00
yueli
6a9e41f53c feat(audit-ui): 审计页 UI 重构 —— 干净模块下拉、变更摘要、抽屉详情、触发来源 
后端：GET /audit/modules 与 /logs 的 modules 改为下发最终选项 [{value,label}]
  · 历史命名（入库管理/采购入库/成品入库/库存管理）折叠进「入库」一项且
    **不再单独列出**，下拉里看不到历史包袱。展开仍只由后端 expand_modules
    负责 —— 前端若自己再拼一份成员表，将来后端加成员会静默失效（本项目
    已经踩过两次这种漂移）。
  · 英文历史 module（image_embeddings 2719 条 / purchase_request 75 条 /
    sys_element 6 条）在这里翻成中文 label，value 保留英文原值否则筛选
    匹配不上。映射表 MODULE_LABELS 从**前端** AuditLog.vue 的 moduleMap
    收进 audit_labels.py —— 那份硬编副本历史上已经漂移过一次。
  · /audit/labels 新增 moduleDisplay {原始值 → 展示名}，同时覆盖聚合成员与
    英文历史值：只覆盖后者会出现「下拉显示『入库』、表格显示『库存管理』」，
    用户会以为筛选没生效。

后端：新增「触发来源」
  · 摘要追加 （来源：/outbound/request） 形式的 URL 尾段（去掉 /api/vN 前缀）。
    解决一个具体误解：业务方看到「入库/库存管理」里有大量非库管人员的
    UPDATE，以为越权改库存，实际是出库/借还/盘点等单据流转触发的自动扣减。
    实测该类 UPDATE 的来源：outbound 1582、outbound/request 424、
    borrow/dispatch 102、stocktake/update-quantity 95 —— 光看"谁改的"永远
    解释不清，必须能看出"哪个流程触发的"。
  · 来源拼在**截断之后**，保证这条关键信息永远不会被截掉。
  · 列表与导出共用 changes_summary，故 Excel 台账同样带来源。

后端：其余
  · 新增 target_keyword（ilike 同时匹配 target_id / target_name），
    放进共用的 _build_audit_query，导出自动支持。
  · action 在响应里归一化为 CREATE/UPDATE/DELETE（复用 audit_labels
    .canon_action，覆盖批量删除/分配/归还等全部历史别名）。库里还有 1573 条
    中文 action，归一后前端不必再为每种历史写法兜底。
  · 新增 summary 字段。不算在模型 @property 上：摘要要把 user_id/base_id
    翻成人名/物料名，需要查库，模型属性里发查询就是 N+1；改为整页一次
    load_ref_maps 批量解析。
  · 过滤对象 repr 脏值（<MaterialBase 3030>）。快照收集早期漏跳关系属性，
    库里留了 1529 条这种值 —— 不是业务数据，真正的值在对应 _id 字段里。
    判据收窄到「<类名 空格 内容>」，避免误伤备注里的「<急件>」。

前端 AuditLog.vue
  · 模块下拉改平铺 [{value,label}]，删除硬编的 moduleMap
  · 新增「操作对象」模糊搜索
  · 合并「操作人」「姓名」两列（判据 username==='system' —— 响应里没有
    operator_type 字段，那是请求参数名，照搬会永远不显示系统标签）
  · 新增「变更摘要」列；操作对象显示为「名称 #id」
  · 操作时间改为恒显示北京时间，不再按浏览器时区换算，与数据库/日报/导出一致
  · 详情弹窗改 el-drawer，按 action 分支渲染：UPDATE 出对比表，
    CREATE/DELETE 出快照属性表，并跳过对象 repr
  · 抽屉顶部高亮展示触发来源（METHOD + URL 告警条）

验证：后端 18 + 22 + 10 项断言全过（模块选项无历史名且「入库」=四值之和、
英文 value 仍可筛选、url_source 边界、来源不被截断、导出口径与列表一致、
权限 401/403/200 矩阵）；vue-tsc --noEmit 与 vite build 均 exit=0。
日报回归：三天附件 490.5K/193.5K/10.3K，6 列结构与改动前一致。
 2026-09-28 10:10:05 +08:00
yueli
7d203b20c1 feat(audit): 按条件导出审计日志，并修 module 口径断裂与详情接口权限漏洞 
需求是"想看某天或某段时间的入库的修改，支持下载或当场查看"。
核查后：筛选与查看审计页早已具备，缺的是导出 —— 但直接加导出会撞上两个
既有问题，故一并处理。

1. 「入库」的 module 口径在 2026-09-10 断过一次

   那天旧的全局监听器 app/utils/audit_events.py 被现行的
   app/core/audit_listener.py 取代（旧模块现已无人 import，是死代码），
   新监听器把入库三表 stock_buy/stock_semi/stock_product 统一归为
   「库存管理」，不再产出「入库管理」：

       入库管理  16118 条  2026-04-22 ~ 2026-09-10
       采购入库   1196 条  2026-03-18 ~ 2026-04-20
       成品入库      8 条  2026-03-23 ~ 2026-04-17
       库存管理   1371 条  2026-09-10 ~

   后果：按单个 module 值筛「入库」会正好在那天断掉，现象是"入库记录突然
   没了"。解法是**查询期别名展开**（audit_labels.MODULE_GROUPS），不迁移
   历史数据 —— 改数据不可逆，而聚合查询无损。

2. GET /audit/logs/<id> 缺权限校验，也没有公司隔离

   此前只有 @jwt_required()，任何登录用户改一下 URL 里的 id 就能读到全部
   审计明细（含 details 里的完整快照）。列表接口有 system_audit 把关，
   详情提供的信息是列表的超集，没道理比列表更宽松。
   现补权限码 + 与列表同一个公司判据；越权与不存在**统一返回 404**，
   区分开来等于告诉探测者"这个 id 存在，只是你没权限"。

3. 筛选逻辑只写一份

   抽出 _build_audit_query()，/logs 与 /logs/export 共用。两处各写一份迟早
   出现"页面上 300 条、导出来 280 条"，而报表对不上比没有报表更糟。

导出实现：
- GET /audit/logs/export，权限码同 /logs；忽略分页参数，导全量。
- 三个工作表：汇总（含本次生效的筛选条件，收件人看不到页面上的筛选框）、
  审计日志（一行一条）、变更明细（一行一个变更字段，可对「字段」列筛选）。
- EXPORT_LIMIT=100000 作熔断。实测全库 5.8 万条导出 2.5MB / 约 3 秒，
  故走同步返回，不引入 export_service 那套异步框架（它还会落盘且无清理）。
  触顶时在文件名与汇总表显式写明，不静默丢弃。
- 顺带补 /audit/modules 的公司隔离（下拉选项此前会跨公司）。

前端（AuditLog.vue / api/audit.ts）：
- 模块下拉分「业务聚合 / 具体模块」两组，聚合项由后端下发，前端不硬编成员；
- 操作类型改多选，提交时 join(',')（后端 split(',') 接收）；
- 导出按钮沿用仓库既有的 blob 下载写法，文件名前端自定。

验证：后端 21 项断言全过（口径断裂、多选别名归一、日期闭区间、公司隔离、
401/403/200 权限矩阵、导出口径与列表 total 一致、附件为合法 xlsx）；
vue-tsc --noEmit 与 vite build 均 exit=0。
 2026-09-28 09:46:34 +08:00
yueli
1d6beaa376 feat(daily-report): 正文保持摘要，新增 Excel 附件给全量明细 
日报此前把明细压到极简（修改只列变更字段≥3 的记录、新增只给模块计数），
"199 条新增只看到 3 个模块名"，查不到某条具体记录改了什么。

但也不能全塞进正文：实测某日 354 条修改展开近 3000 行，客户端渲染卡顿，
部分企业邮件网关会把超长自动邮件判为垃圾或截断 —— 发件方照样收到 250，
表面看一切正常，这比"信息少"更难排查。

故拆成两路：正文保持摘要（render），附件给全量明细（render_excel），
六个工作表不设 DETAIL_MIN_FIELDS 之类的阈值。

- email_service: send_email/send_email_async 支持 attachments。数据是内存
  字节、不落盘；中文文件名走 RFC 2231；.xlsx 用官方 MIME 类型，写错会让
  Outlook 当成未知二进制、附件无法直接打开。
- audit_export_service: 新增。审计日志 → 可读值/Excel 的共用层。
  「同一条「实际审批人ID: 7」一边翻了人名一边没翻」这类漂移，比不翻译更
  难发现，故取值/翻译/排版逻辑集中在此，由日报与审计页导出共用。
- daily_report_service: 私有副本改为消费上述共用层（纯重构）。
  附件大小与重构前逐字节一致（490.5K / 193.9K / 10.3K），行为未变。

附件生成失败时降级为纯文本正文继续发送，但记 error 级日志 —— 降级后邮件
看起来完全正常，不留显眼日志的话附件静默丢失可以持续几个月没人发现。
 2026-09-28 09:46:25 +08:00
yueli
b2a2f513ae fix(email): 补齐 Date 与 Message-ID 邮件头 
问题：本项目发出的所有邮件都缺少 Date 与 Message-ID —— 这两个头
RFC 5322 要求（Date）或强烈建议（Message-ID）携带，而 smtplib
**不会自动补**，构造 MIMEMultipart 时必须自己加。

为什么值得修：缺这两个头是反垃圾引擎的经典扣分项（"来源不明的
自动化邮件"特征）。而它是**静默失败** —— 发件服务器照样回
250 Data Ok，客户端完全看不出邮件在收件方被降权。

诊断依据：抓取完整的 SMTP 会话（set_debuglevel(1)）后，报文里
只有 Content-Type / MIME-Version / From / To / Subject 五个头。

★ 需要说明的是：**无法证明这就是此前邮件丢失的原因**。用户实测
  未加此头的邮件也能收到，加了之后仍有一封未送达。此改动是补上
  一个确定存在的规范缺陷，不等同于修复了投递问题。

影响面：send_email() 是全局共用的发信函数，库存预警、出库/借库
审批通知等所有通知邮件一并受益。
 2026-09-23 17:41:35 +08:00
yueli
ded5dfd7b3 feat(report): MOM 系统日报（纯模板，不接 AI） 
每天 17:30（北京时间）自动汇总当日 新增/修改/删除、出库、借库，
渲染为纯文本邮件发送。

为什么不用 AI
--------------
此前那份日报由 Dify（外部 AI 服务，见 api/v1/ai_proxy.py）生成，
好处是能写人话，代价是：
  · 外部依赖一断，整份日报就没了 —— 这正是"AI 坏了"之后发生的事；
  · 按次计费、走网络、要管密钥；
  · **会在报表里编数字**，而日报是给人做决策用的，数字必须可信。
日报是固定格式的结构化统计（计数 + 清单），本来也不需要创造力。
数据全在库里：audit_logs / trans_outbound / trans_borrow。

口径与审计页保持一致
--------------------
  · action 经 canon_action() 归一化（历史数据里 CREATE 与「新增」混用，
    不归一会漏掉早期数据）；
  · 默认排除 system 占位账号（与审计页默认的"真实用户"视图一致）。
  · 凡有上限处一律显式写明「另有 N 条」，不静默截断。
  · 变更值全部翻译成人类可读：状态码按模块查表、审批人/物料 ID → 名称、
    布尔 → 是/否、人名串规整。翻不动就原样显示 —— 报表里的错译比裸数字
    更难被发现，也更危险。

★ 顺带修掉两个既有缺陷（日报每天都会走这条路径，不修会一直中招）：

1) 定时任务被 8 个 worker 重复执行
   gunicorn.conf.py 配了 8 worker，而 run.py 在**模块级**启动 APScheduler
   —— gunicorn 未开 preload_app，每个 worker 独立 import 一次 run.py，
   于是每个 worker 各起一份调度器，同一 cron 任务被并发执行 8 次。
   现有库存预警邮件因此每天重复发 8 封。
   新增 app/utils/job_lock.py：用 PostgreSQL 会话级咨询锁做跨进程互斥，
   抢到锁的 worker 才执行，其余静默跳过。不引入新组件（compose 里没有
   redis，redis_client 恒为 None，相关装饰器全程 fail-open，指望不上）。
   实测 8 线程并发抢锁恰好 1 个成功。

2) 邮箱授权码被打印进日志
   email_service.py 的 print(f"[DEBUG send_email] cfg = {cfg}") 会把含
   password 的整个配置打到 stdout → docker logs。改为只打非敏感字段。

新增配置：MAIL_DAILY_REPORT_RECIPIENTS（逗号分隔，默认 duxingchen@iris-rs.cn）
 2026-09-23 17:16:26 +08:00
yueli
ad2d27cd72 refactor(audit): 审计中文映射收敛为后端唯一来源 
问题：同一套「字段名 → 中文」映射存了三份手工同步的副本 ——
前端 AuditLog.vue 的 fieldMap（约 95 个字段）、后端 api/v1/audit.py 的
ACTION_ALIASES，另有若干内联的 status 映射散落在 service 层。
改一边漏一边就会漂移，页面上冒出英文列名或对不上的中文。

改动：
  · 新增 app/utils/audit_labels.py 作为**唯一来源**，统一提供
    操作类型归一化（canon_action）、字段名中文化（field_label）、
    码值中文化（enum_label / bool_label / person_name_label）、
    ID 指向登记（id_ref_of）。
  · api/v1/audit.py 改为从该模块 import，删掉本地副本。
  · 新增 GET /audit/labels 下发映射（静态标签，免权限码；审计页本身
    已由 system_audit 把关）。
  · 前端 AuditLog.vue 删除本地 95 行 fieldMap，改从接口拉取；
    拉取失败时未命中项原样显示，是可控降级。

★ 码值必须**按模块**翻译：同名 status 在出库/借还/报废里含义完全不同
  （出库的 3 是「已出库」，报废的 3 是「已执行(已报废)」），
  不区分模块会把报废单显示成已出库。借还模块下还混着字符串状态
  （borrowed/returned），因其两张表共用 status 列名。
  故映射按 (模块, 字段) 匹配，未登记再退回字段名。

★ ID 字段同理：parent_id 在「系统管理」里是菜单的上级菜单，在「BOM管理」
  里是物料节点 —— 指向完全不同的表。

验证：前端 vue-tsc 改前改后均为 565 个错误、去除行号后**报错集合完全相同**，
未引入新错误；GET /audit/labels 实测返回 200。
 2026-09-23 17:16:20 +08:00
yueli
fc5e62c848 feat(purchase): 新增「活跃采购单」判定与在途量计算模块 
防重复采购的唯一真相源。刻意回答两个不同的问题，别混用：
- active_purchase_exists()  有没有人在买？      → 展示用
- in_transit_subquery()     已经买了多少还没到？ → 算术用

活跃单定义：status 0/1，或 status=3 且累计入库 < 采购量。
status=4（强制结案）刻意不在其中 —— 短交不补发、来料拒收不补发这类
异常单永远达不到采购量，靠库管强制结案解锁，避免物料被永久占用。

「部分到货」无需改表即可算出：StockBuy.request_id 早已存在，且
StockBuy.in_quantity 是入库原始量（不被出库扣减，区别于 stock_quantity），
按 request_id 聚合即得每张单的累计到货量。
 2026-09-18 14:30:40 +08:00
yueli
6cb30a21fd feat(material): 采购链接接入读写映射与服务层 
· models/base.py：新增 purchase_link 列（text）并加入 to_dict（purchaseLink）
· field_permissions.py：读过滤映射 purchaseLink → material_list:purchaseLink
· inbound/base.py：POST 与 PUT 两处 field_to_perm 同时补入（漏掉任一处，
  新增/修改就会各缺一半）
· base_service.py：create_material 写入、update_material 按字段存在与否更新

★ 写侧刻意**显式纳入映射**而非依赖「不在映射中→默认允许」的兜底分支 ——
  那个分支正是上一轮附件备注「谁都能写」的成因，新字段不再走它。

验证（6 个角色）
    SUPER_ADMIN / SUPERVISOR / WAREHOUSE_MGR / INBOUND → 读✓ 写✓
    OUTBOUND / SALES                                   → 读✗ 写✗
  读写逐角色一致；超管走 material_list:* 通配分支、过滤整段跳过（已单独复核）。
 2026-09-17 11:26:36 +08:00
yueli
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
yueli
e437b3cece feat(records): 高级筛选引擎 + 出库记录接入 
一、新增共享工具 app/utils/advanced_filter.py
  系统内已有该模式（material/list.vue、stock/inbound/buy.vue），
  沿用其既有约定：参数名 advancedFilters、值为 JSON 字符串、
  操作符 eq/ne/contains/not_contains/ge/le。

  · parse_advanced_filters() 解析并规整，坏输入退化为空列表不影响主查询
  · build_predicate() 单条件 → SQLAlchemy 谓词，未登记字段返回 None 杜绝列注入
  · build_material_name_select() 物料名三表联查（buy/semi/product JOIN material_base）

二、★ 父子关系处理（本次核心）
  记录接口返回的是**按单号分组的订单**，而用户筛选字段多落在**明细行**上。
  若直接 .filter(TransOutbound.sku.ilike(...))，会在 GROUP BY 前收窄明细范围，
  展开行里的兄弟明细会凭空消失。正确做法是先求「含匹配明细的单号集合」
  再让主查询按单号 IN 过滤。

  实测对照（单 OUT-20260811-1519-0003，21 条明细）：
    按其中一条 SKU 筛选 → 子查询法保住全部 21 条；直接 filter 只剩 1 条。

三、★ 否定操作符语义（NOT IN）
  子级字段的 ne / not_contains 不能直接用 SQL != / NOT LIKE —— 那表达的是
  「本单存在某条不等于 X 的明细」，多明细单几乎必然成立，等于筛选失效。
  用户意图是**整单排除**，故 apply_child_condition() 统一：
    肯定 → order_no     IN (含匹配明细的单号)
    否定 → order_no NOT IN (含匹配明细的单号)
  两者子查询完全一致（都用肯定形式谓词），仅外层取反。
  父级字段（单号/操作人）仍走标准 SQL 谓词，语义无歧义。

四、出库记录接入（前端弹窗 + 后端接线）

验证：
  eq 0000000002 → 1 单；material_name contains 白板 → 16 单
  sku ne 0000000002 → 394 = 395-1，含该 SKU 的单被整体排除
  material_name not_contains 白板 → 379 = 395-16
 2026-09-10 13:05:59 +08:00
yueli
67d3113fe1 fix(permission): 记录管理者视角仅超管/主管/仓库管理员，去掉入库员/出库员 
- PRIVILEGED_VIEWER_ROLES 收敛为 SUPER_ADMIN/SUPERVISOR/WAREHOUSE_MGR
- 入库员(INBOUND)、出库员(OUTBOUND)按普通处理：借还/出库记录只看自己
 2026-09-09 11:19:09 +08:00
yueli
4146f35010 feat(permission): “出库/借库需审批”开关权限化——仅主管/超管可见可改 
- 新增权限码 material_list:isApprovalRequired，授予仅 SUPER_ADMIN/SUPERVISOR（收回其它角色）
- 物料列表该列仅持码角色可见；后端批量端点与字段脱敏均改按新码校验，其余角色看不到值也无法改
 2026-09-09 10:47:36 +08:00
yueli
4cd3eefdf4 feat(borrow,outbound): 默认免审批改造——命中物料需审批才走原流程 
- models/base.py 加 is_approval_required 列及 isApprovalRequired 序列化；field_permissions 登记
- 新增 POST /inbound/base/batch-approval（批量设需审批，仿批量质检）
- borrow_service.submit_approval / outbound_service.create_request：明细含需审批物料→须选审批人走原审批；否则创建即 status=1(待库管执行)、不发审批邮件
- 判定按 (name,spec_model) 反查启用物料
 2026-09-09 09:31:18 +08:00
yueli
9622baf76e fix(borrow,outbound): 记录查看按角色收窄——普通只看自己，库管/主管/超管/跨域看全部 
- decorators 新增 is_privileged_viewer（SUPER_ADMIN/SUPERVISOR/WAREHOUSE_MGR 或 crossDomain）
- 借库记录列表：非管理者强制 applicant_id=当前用户
- 出库记录列表+详情：非管理者强制只看自己/无权访问他人单(403)
 2026-09-09 09:31:01 +08:00
yueli
7e4524ae42 fix(warning): 预警字段被 field_permissions Default Deny 规则错误过滤 
- MaterialBase 映射中新增 warningStatus/warningEnabled/warningRed/warningYellow/warningRedEmails/warningYellowEmails 字段
- 新增 _permits() 函数支持通配符权限匹配 (material_list:* 覆盖所有 material_list:xxx)
- 修复 apply_strict_rbac 使用 _permits 替代直接 in 检查

根因: field_permissions.py 的 STOCK_FIELD_RBAC_MAPPING 中没有预警字段映射,
apply_strict_rbac 的 Default Deny 规则会删除所有不在映射中的字段,导致前端永远收不到预警数据。
 2026-08-11 13:28:47 +08:00
yueli
fd506775c1 fix: send_email_async 主线程预取 config 传入 daemon 线程，修复异步邮件因丢失 Flask context 导致 MAIL_ENABLED=false 2026-07-17 14:27:39 +08:00
yueli
08b7674610 fix: 后端数量字段纳入RBAC — StockBuy/Semi/Product 的 in_quantity/stock_quantity/available_quantity 从 None 改为显式权限码 2026-07-17 13:45:23 +08:00
yueli
3c0954598c perf: 综合安全加固 — RBAC严格映射+异步邮件+字段权限白名单+前端对齐+导入模板 
本次提交包含本会话所有修改的最终统一提交

## 权限系统重构
- permission_service.py: 添加入库/采购操作元素 + ensure_default_permissions
- field_permissions.py: 严格1-to-1 Default Deny 字段映射(StockBuy/Semi/Product/MaterialBase)
- decorators.py: _expand_operation_perms 双向粒度桥接 + prevent_double_submit
- deploy_production.sql: 修复 sys_element 别名码(qty_inbound→in_quantity)

## 采购模块
- purchase.py: 权限驱动可见性 + inbound_purchase独立权限 + 价格字段过滤
- purchase_service.py: 异步邮件 + 三阶段批量模糊匹配防N+1
- purchase/index.vue: canApprove严格操作权限 + upload重复修复

## 导出/入
- base_service.py: export_excel 流式写入防OOM + get_latest_specs 优化
- import_service.py + import_api.py: Excel批量导入（模板+预览+执行）
- ImportDialog.vue: 三步骤导入弹窗

## 异步邮件
- email_service.py: send_email_async (守护线程)
- inventory_task.py: send_email→send_email_async

## 前端对齐
- product/semi/buy.vue: 列对齐in_quantity/stock_quantity/available_quantity + localStorage缓存V2
- buyOdoo.vue: 排序修复 + 导入按钮 + 移除点击展开加载
- BomManage.vue: 懒加载分组 + 导入按钮
- list.vue: 导入按钮
- Selection.vue + borrow/apply: BOM匹配修复 + 导入按钮
- outbound/create.vue: 出库类型必选
- AppMain.vue: 移除transition白屏修复
- material_base.ts, outbound.ts, bom.ts, stock.ts: 新增API函数
 2026-07-17 13:07:12 +08:00
yueli
347f20497c feat: Redis幂等锁 + 关键端点防重复提交 
## decorators.py
- 新增 @prevent_double_submit(lock_timeout=5) 装饰器
  Redis key: idem:{user_id}:{path}:{MD5(body)}
  锁存在→409, 不存在→setex→执行业务→delete
  Redis不可用时fail-open降级放行

## purchase.py
- POST /purchase (创建): +@prevent_double_submit
- PATCH /purchase/<id>/approve (审批): +@prevent_double_submit

## outbound.py
- POST /outbound (出库): +@prevent_double_submit

## transactions.py
- POST /borrow/dispatch (借库扣减): +@prevent_double_submit
 2026-07-16 13:08:37 +08:00
yueli
e313f575bf perf: 系统级异步邮件 — 消除SMTP阻塞导致的10-15秒UI冻结 
## email_service.py
- 新增 send_email_async(): threading.Thread(daemon=True) 包装 send_email()
  无需 Flask app_context (send_email仅用os.getenv+smtplib)
- 6处 send_email→send_email_async 替换

## inventory_task.py
- 库存预警 send_email→send_email_async (2处)
 2026-07-16 11:26:12 +08:00
yueli
0b75740ae0 feat: 权限系统重构 — 操作权限双向展开 + 启动时自动补全默认权限 
## permission_service.py
- init_all_menus: menu_defs 新增 inbound_purchase(采购申请) 菜单项
- init_all_menus: 创建 inbound_purchase:operation 操作元素
- 新增 ensure_default_permissions(): 启动时从 sys_user 提取活跃角色,
  对空权限角色自动补全默认菜单(按角色类型分级)
- 自动迁移: 已有 inbound_buy 权限的角色 → 自动获得 inbound_purchase
- SUPERVISOR 启动时自动获得 inbound_purchase 菜单权限

## decorators.py
- _expand_operation_perms 改为双向桥接:
  正向(inbound_buy:operation←inbound_buy:write)→通过
  反向(inbound_buy←inbound_buy:operation)→通过(可编辑隐含可读)
- 新增详细诊断日志,记录展开路径和失败原因

## __init__.py
- 启动时调用 PermissionService.ensure_default_permissions()
 2026-07-16 11:25:41 +08:00
yueli
e1417d740a feat: 全模块公司隔离 + crossDomain权限码动态跨域控制 
- get_current_company_filter: 新增_has_cross_domain_permission, 权限码替代硬编码
- 补全11个Service的get_current_company_filter调用(semi/product/service/outbound/bom/trans/scrap/summary)
- base/search修复: search_material此前无隔离, 已补全
- get_current_company_filter兜底: JWT缺company_name时返回__NO_COMPANY__防止放行
- permission.py: _get_operator_company补全返回值, 修复权限页保存逻辑
- 新增crossDomain迁移脚本, element_type=element挂system_mgmt下
 2026-07-15 11:11:40 +08:00
yueli
9cae1cc44c feat: 跨域访问从硬编码改为权限码crossDomain动态控制, 新增SQL迁移脚本 2026-07-15 09:22:58 +08:00
yueli
4f5965db02 feat: JWT多租户数据权限隔离 & 主管系统管理权限 & 含税单价补齐 
## 多租户公司数据隔离
- 新增 get_current_company_filter() 工具函数 (decorators.py)
  SUPER_ADMIN: 可传company_name参数过滤或传ALL看全量
  其他角色: 强制隔离到JWT中的company_name
- 重构 base_service.py / buy_service.py: 用集中式函数替换内联公司过滤
- SysRolePermission 表新增 company_name 字段，支持同角色不同公司权限
- get_user_permissions() 新增 company_name 参数，查公司定制+全局模板权限
- permission.py API 新增 @permission_required 拦截 + 公司过滤
- 19个API/service文件传递 company_name 到权限查询

## 主管系统管理权限
- delete_user() 允许SUPERVISOR删除同公司用户 (原仅SUPER_ADMIN)
- get_all_users() 新增 company_name 参数过滤
- 用户列表/权限分配 API 应用 get_current_company_filter()
- 前端 UserCreate.vue: 超管可见公司下拉框，主管隐藏部门字段

## 前端多租户适配
- material/list.vue / buy.vue: 公司下拉框仅超管可见，默认ALL
- UserCreate.vue: 新增搜索栏公司筛选，部门字段按角色显隐
- auth.ts: getUserList() 支持 params 参数

## Bug修复: 含税单价字段补齐
- buy.vue: 表格列/高级筛选/排序/权限映射新增 post_tax_unit_price
- buy_service.py: allowed_fields/sort_field_map 新增 post_tax_unit_price
 2026-07-13 15:12:22 +08:00
DXC
5c0c1632c3 fix(审批邮件): items_json序列化Bug修复 + 邮件方法出库/借库物理隔离 2026-06-12 15:04:57 +08:00
dxc
7d828d3ebf 版本变更V3.35将图像的处理统一更换到新表当中 2026-05-26 12:01:58 +08:00
dxc
fb5b8d873b 版本变更V3.35将图像的处理统一更换到新表当中 2026-05-26 11:28:26 +08:00
DXC
1da4b454cd feat: 新增物料/入库单实时 CLIP 向量提取（新建+更新），修复 I/O 延迟和路径解析静默失败 2026-05-25 10:04:32 +08:00
DXC
c273f5a9d9 feat: 以图搜图功能升级（跨表UNION检索 + 拍照识图入口 + 批量向量初始化脚本） 2026-05-21 15:43:45 +08:00
DXC
1a7c06f197 feat: 添加以图搜图功能（CLIP ONNX + pgvector）+ Dify会话修复 + 版本升至V3.30 2026-05-21 14:09:57 +08:00
DXC
3cb31c2b67 fix: 修复 JWT 幽灵令牌漏洞，新增 Dify 权限过滤服务 2026-05-18 16:16:50 +08:00
DXC
3dae206828 feat(outbound): 完善出库审批邮件通知逻辑，支持申请人与审批人同时收到邮件（带物料明细），审批通过后申请人和库管均收到带物料明细的通知 2026-05-12 13:42:15 +08:00
dxc
259f3a7e0d 4.29扫码获取库位小工具接口 2026-04-29 15:40:43 +08:00
DXC
8276597a67 fix(email): 审批通知逻辑重构 - 通过时同时通知库管和申请人，驳回仅通知申请人；精简 DEBUG 日志 2026-04-29 09:10:34 +08:00
DXC
ccbce82c2e fix(email): 审批通过后库管通知增加明细+DEBUG日志，修复MAIL_DEFAULT_SENDER格式问题 2026-04-28 16:46:12 +08:00
dxc
183b93012e 4.28 2026-04-28 16:07:11 +08:00
DXC
1205d9c7e8 feat(audit): 优化审计日志的人性化展示 2026-04-22 10:44:13 +08:00
DXC
4b794b9bcc feat(audit): 添加全局无侵入审计日志拦截器 2026-04-22 10:41:15 +08:00
DXC
f8f5b05d7d refactor(audit): 废弃装饰器+分离架构，改为监听器单体直写入库 2026-04-20 16:04:01 +08:00
DXC
7e72c12f30 fix(audit): 修复 decorators.py 中缺失 has_request_context 导入导致的致命 NameError 2026-04-20 15:10:12 +08:00
DXC
decb7f5e1f debug(audit): 添加X光调试-追踪断点 2026-04-20 15:01:20 +08:00
DXC
1c8def7e6f refactor(audit): 分离架构-监听器计算装饰器入库 2026-04-20 14:41:40 +08:00
DXC
381d1fa675 feat(audit): 平滑升级-监听器+装饰器共存，装饰器自动检测并跳过已处理日志 2026-04-20 13:15:25 +08:00
DXC
a52ced0375 fix(backend): resolve DetachedInstanceError in audit_log, add pessimistic locks for stock adjustments, and eliminate N+1 queries with eager loading 2026-04-02 18:44:12 +08:00
DXC
46dd8f1c3a fix(auth,audit): ensure display_name persists in token refresh and add fallback in audit log 2026-03-25 11:16:13 +08:00
DXC
032479fe38 fix: capture and persist target object names for delete, outbound, and borrow operations in audit logs 2026-03-20 15:47:13 +08:00
DXC
4223a95f10 feat: generate permission sql for stocktake modules and implement single-device login restriction 2026-03-20 09:11:54 +08:00