|
|
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 |
|
|
|
c7f85880a9
|
feat(scrap): 新增对内接口，让 Track 能提交生产报废
料一经出库领用，那条库存行的可用量就扣掉了，走不了标准库存行报废。
本接口内部做两件事：① 走逆向物流「从出库单退回(不良品)」→ 在管不良品；
② 对这笔在管量提交报废申请。两者在**同一个事务**里，要么都成要么都不成。
- 鉴权用 X-API-Key（config.MOM_INTERNAL_API_KEY），与 TRACK_WEBHOOK_KEY
刻意分离：方向相反、权限不同，独立轮换不连坐。未配置一律 503（Fail-Closed），
不静默放行 —— 一个默认开着的写接口比没配好的更危险。
- 刻意收紧：is_defective 恒为 true、need_reissue 恒为 false，都不由请求体
控制。良品分支会往库存行加数量，一个泄漏的密钥就能凭空造库存。
- track_ref 必填：Redis 未部署，唯一索引是唯一的并发防线。
- 退回逻辑从 inbound/stock.py 抽到 services/return_service.py：内部接口没有
JWT，而视图里夹着 get_current_company_filter/_normalize_user_id，不抽没法复用。
API 层保留薄包装，restock 等既有调用方一行不用改。
|
2026-09-23 15:17:44 +08:00 |
|
|
|
de34a939d0
|
feat(track): 新增 TRACK_ROUTES 多实例路由表配置
Track 现在有两个独立实例（IRIS / LICA），MOM 此前所有 Track 配置都写死
指向 IRIS，LICA 的业务拿不到入库/出库联动，且 /track-lookup 对 LICA
员工是坏的。
新增 TRACK_ROUTES 环境变量（JSON），按 material_base.company_name 决定
业务落到哪个实例：
{"IRIS": {"api":..., "inbound":..., "outbound":...}, "LICA": {...}}
原有三个扁平变量（TRACK_API_URL / TRACK_WEBHOOK_URL /
TRACK_OUTBOUND_WEBHOOK_URL）保留为「未命中路由表」时的回落默认值；
TRACK_ROUTES 缺省为空表时，行为与改造前逐字节一致（向后兼容）。
⚠️ JSON 解析失败直接抛异常让进程起不来（fail fast）——路由表写坏却静默
回落，会造成"某些公司悄悄断链"，比启动报错难排查得多。
docker-compose.yml 用容器名互访（inventory_api / track_backend /
lica_backend 三个容器同属 projects_default 网络，不走宿主机端口）。
判定维度用 company_name 而非 category：实测 category 两个方向都会错
（10 条 LICA 物料挂在 IRIS/ 分类下；IRIS 分类里含 "IRIS/成品/LICA/..."
那是产品线名不是部门名，共 171 条）。
|
2026-09-22 13:13:52 +08:00 |
|
|
|
bee037f925
|
feat: MOM 扫码入库对接 Track 产品身份证自动填充
- 半成品/成品入库弹窗顶部新增'扫码入库'按钮,打开扫码面板(扫码枪/摄像头)
- 扫码 Track 身份证后自动填充物料信息与序列号,不再二次搜索
- 后端新增 track_query_service(httpx 调 Track lookup)、track-lookup 接口
- 入库成功后 notify_track 通知 Track 闭环
|
2026-09-01 13:52:56 +08:00 |
|
|
|
ccbce82c2e
|
fix(email): 审批通过后库管通知增加明细+DEBUG日志，修复MAIL_DEFAULT_SENDER格式问题
|
2026-04-28 16:46:12 +08:00 |
|
|
|
62c0e3738e
|
fix(outbound+trans): 修复POST接口错误数据清洗导致的sku/quantity字段被清除Bug，并新增出库审批工作流全链路
|
2026-04-28 16:02:34 +08:00 |
|
|
|
4223a95f10
|
feat: generate permission sql for stocktake modules and implement single-device login restriction
|
2026-03-20 09:11:54 +08:00 |
|
|
|
e4632086a1
|
feat: 重构鉴权系统为双Token无感刷新，并增加前端Token过期安全预判机制
|
2026-03-10 09:45:41 +08:00 |
|
|
|
13590b1fac
|
超级管理员登录设置
|
2026-02-04 13:30:07 +08:00 |
|
|
|
3afea217b7
|
物料-采购件入库页面功能实现
|
2026-01-27 15:50:23 +08:00 |
|
|
|
2f8a5c55b1
|
python-flask和Vue两种模式初模板
|
2026-01-26 17:00:12 +08:00 |
|
|
|
ee9f4aed3e
|
修正git管理关系
|
2026-01-26 13:47:53 +08:00 |
|
