|
|
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 |
|
