|
|
edd43fec29
|
fix(webhook): MomOutboundPayload 补 outbound_type，与 LICA 实例解析一致
MOM 一直在载荷里发 outbound_type（出库类型：SALES 销售 / USE 领用 /
PRODUCTION 生产），本实例此前没声明该字段，被 Pydantic 静默丢弃。
当前没有任何代码读它，补上不影响行为；目的是让两个实例对同一载荷的解析结果
一致 —— 否则将来谁写了读这个字段的代码，会在 LICA 拿到值、在本实例拿到 None，
而且这种不一致是静默的，不会报错。
|
2026-09-22 13:46:11 +08:00 |
|
|
|
3c94faf078
|
feat(audit): MOM 回调归因到实际操作人，不再显示「未认证」
外部回调走 X-API-Key 鉴权、没有 JWT，JWT 依赖不执行，审计中间件读到的
request.state.audit_user 永远是空 —— 操作审计里就出现一堆没有归属的
「外部系统对接」记录，看不出是谁扫的码。
MOM 载荷里本来就带着实际操作人（operator，即 MOM 侧扫码的那位），写进
request.state 即可让审计归因到人；顺手解析中文姓名（查不到也不影响审计，
前端会回退显示账号）。
⚠️ 调用位置必须在 X-API-Key 校验【之后】：密钥不对说明载荷本身就不可信，
此时把 operator 写进审计等于允许伪造人。放在部门校验之后同样有意为之 ——
被拦下的外来消息不该留下任何归属痕迹。
取不到操作人时写 "MOM系统" 而非留空：「MOM系统」至少说明这是一次机器回调，
比继续显示「未认证」（读起来像"一个匿名的人"）更准确。
实测：MOM 回调后审计记录显示实际操作人姓名；无 operator 时显示「MOM系统」。
|
2026-09-22 13:44:05 +08:00 |
|
|
|
817183062d
|
feat(webhook): MOM 回调的部门归属分流 —— 只放行 IRIS 与空白值
MOM 现在同时对接 IRIS 与 LICA 两个 Track 实例，按载荷里的 company_name 分流。
实现：
· MomInboundPayload / MomOutboundPayload 补 company_name 字段
（不补的话会被 Pydantic 静默丢弃，分流无从谈起）
· 新增 _is_foreign_company()，在**鉴权之后、匹配产品之前**拦截
· 拦截时返回 200 + matched=False + reason="ignored_company" —— 与「未命中」
保持同一契约，避免 MOM 侧把它当成故障反复重推
⚠️ 判定刻意做成「只排除已知的外来公司」（黑名单），而非「白名单只认 IRIS」：
MOM 在无法确定公司归属时会回落到扁平配置，该配置指向本实例 —— 这类消息的
company_name 会是空 / 缺失。若按白名单把空白也拒掉，它们就彻底丢了：MOM
那边已收到 200、认为投递成功，不会再重推。同理，未见过的新值也一律照常处理。
reason 的取值 "ignored_company" 与 LICA 实例（~/track-lica）保持一致 —— MOM 侧
不解析它，但排查时两边日志要对着看，字段名不一致会白白浪费时间。
实测：
· LICA 载荷 → {"ok":true,"matched":false,"reason":"ignored_company"}
· IRIS/空串/缺失 → 照常处理
· 无 X-API-Key 仍返回 401（鉴权未被绕过）
|
2026-09-22 13:43:52 +08:00 |
|
|
|
5290d83463
|
feat: MOM 撤回出库强制回滚通道
MOM 把误点出库的设备物理回滚到仓库时，Track 被动跟随 MOM 的权威物理状态。
【撤回信号识别】
- action / event 里的 revoke / rollback / revert / cancel 子串匹配
（MOM 侧字段命名尚未冻结，刻意宽松，避免对方改词就整条链路失联）
- 无显式标记但产品正处于「已出库」时，按"已发货设备收到入库回调 = 货回来了"
隐式判定
【匹配放宽】
- 常规入库仍严格要求 current_location_id == virtual_warehouse
- 撤回信号、或 payload 带 serial 时才放行「已出库」产品 —— 出库回调已把
location 置为 None，不放宽则撤回必然失配、静默返回 matched=False
- 刻意不给 sku 兜底也无条件放宽：同型号可能多台，放宽会误标到别的设备
【特权通道】
- 强制覆写 overall_status=已入库 + 位置回滚 virtual_warehouse，优先级高于
task_service 的【绝对物理终态保护】。两者方向刻意相反：那套约束的是
"车间内部流转不许用工序名抹掉物理终态"，而本接口是物理事实的权威来源。
代码内已留醒目注释，防止后续维护者误加状态互斥校验
- 改用 sync_product_status 统一双字段同步（原先硬编码 status="ARCHIVED"
绕过了 lifecycle.py 的约定），并把 status 变化一并计入 changed，
避免"状态与位置本就正确时纠偏不提交"
【撤回留痕】
- 追加「撤回出库(重新入库)」主线节点。名称里的「入库」二字是必须保留的契约：
product_service._has_warehouse_task 用子串判定仓库节点，若只有"出库"会让
location==virtual_warehouse 的产品被注入假的「待仓库收货」虚拟节点，
出现"已入库却在等收货"的自相矛盾
【重构】
- 抽出 _pick_warehouse_log_task / _match_inbound_product 复用，出库回调同步简化
|
2026-09-21 11:21:03 +08:00 |
|
|
|
d666bbd4ed
|
feat: 直接完结通道与报表口径收口（后端）
【直接完结：保留动作，剥离状态】
- transfer_task 权限硬拦截：仅 SUPER_ADMIN / SUPERVISOR。判据取签名保护的
operator_role，刻意不用客户端可通过 ?operator_id= 伪造的 operator_id
- 直接完结【不再改写】overall_status —— 它只是任务闭环动作，不改变物理状态。
已出库设备完结后依然是「已出库」，回归 WIP 矩阵的已出库列
- 物理终态保护：create_task / receive_task / transfer_task 三处写入点统一加
_is_physical_terminal 守卫，禁止用任务名覆写 已入库/在库/已出库。
历史缺陷：「发货测试」会把设备的「已出库」标识静默抹掉，跨报表口径随之打架
【位置与工序口径】
- _recalc_product_location：已出库且闲置 → 位置清空（货发走就离场）。
只清「已出库」；已入库/在库的设备确实还在仓库里，位置必须保留
- MOM 出库回调同步清空 current_location_id
- 新增 ProductResponse.current_step：只认活跃主干任务，无活跃任务时返回
宏观终态或空。不再让已 COMPLETED 的历史工序（扫码出库/测试…）冒充"当前工序"
【售后烙印去死锁】
- 拆分 OUTBOUND_QC_STEPS(发货测试) / AFTER_SALES_REPAIR_STEPS(售后维修)
- resolve_phase_for_step 与 _mark_after_sales_if_reactivated 双双改为仅
「售后维修」触发 AFTER_SALES，解除「已出库 + 发货测试」被永久烙印的死锁
- PRODUCTION_OVERALL_STEPS 补入「发货测试」，使出厂质检在生产阶段合法
（否则 _enforce_step_isolation 会把已出库设备的发货测试直接 400）
【游魂收口】
- get_wip_matrix / get_wip_matrix_detail 的 is_terminal 增加"名下再无任何活跃
任务则视同终结态"，让被直接完结的生产设备接受时间筛选，不再恒挂在看板上
冒充在制。两处必须一字不差同步，否则会出现"矩阵有数、下钻为空"
|
2026-09-17 17:05:42 +08:00 |
|
|
|
262e28b9f2
|
fix: 仓储任务节点修复(assignee=None + WAREHOUSE 类型) + 前端防御性渲染
- webhook 生成任务 assignee_id 置 None,不再填中文,避免前端解析报错跳过渲染
- task_type=WAREHOUSE,并同步 isMain 判断(后端+双端前端)使其画在中央主干道
- 前端对扫码入库/出库任务:不请求用户数据,直接显示 📦 + 'MOM 仓储系统'
|
2026-09-01 17:25:22 +08:00 |
|
|
|
5407e2135f
|
feat: Webhook 入库/出库后动态生成扫码任务节点与操作日志
- mom-inbound/mom-outbound 在标记已入库/已出库后,追加'扫码入库/扫码出库'主线任务
- 新任务 parent_task_id 取最后一个主线任务,task_type=TRANSFER 保证画在主干道
- 生成 TaskRecord 操作日志,前端流转树最底部长出节点
- 幂等:已存在同名任务则不重复插入
|
2026-09-01 16:55:13 +08:00 |
|
|
|
2b889b99d6
|
fix: webhook 匹配支持 external_serial 外部业务序列号
- mom-inbound/mom-outbound 用 or_ 双字段联合匹配 serial_number 与 external_serial
- MOM 推送 ceshi123 等自定义序列号时也能精准认领产品并闭环状态
|
2026-09-01 15:25:42 +08:00 |
|
|
|
73faa1fd93
|
feat: Track 打通已完成/已入库/已出库状态闭环与外部联动
- 完工转交入库同步 status=COMPLETED;MOM 入库/出库回调同步 status
- 新增 mom-outbound webhook(发货出库标记已出库),lookup 返回 material_id
- VALID_OVERALL_STATUS 新增已出库;update_overall_status 同步 status 字段
- WIP 矩阵区分已入库/待仓库收货;虚拟节点正确处理已出库/转入在库人
|
2026-09-01 13:53:24 +08:00 |
|
