duxingchen/track
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
396 Commits 3 Branches 0 Tags
7635802a42bcde97feb4d3b975ec3b658d8f0876
Commit Graph

56 Commits

Author SHA1 Message Date
openhands
7635802a42 feat(audit): 新增操作审计日志（表/中间件/查询接口）+ 角色常量收敛 
背景：系统此前没有操作审计。task_logs 的 task_id 是 NOT NULL 外键，只能挂在
任务上，且全项目仅 4 处写入点 —— 登录、导出、产品增删改、收编完全不留痕。
需求方整理的问题清单里「无审计日志查看页」正源于此：不是没有页面，是没数据。

设计参考 MOM(KCGL) 的 audit_logs / audit_listener，但按 Track 栈做了取舍：

1) 写入时机：MOM 用 SQLAlchemy event listener + 同事务写入，优点是零侵入，
   缺点是**业务回滚时审计一起消失**，而失败/被拒的操作（越权尝试、参数错误）
   恰恰最需要留痕。Track 改为响应生成后用**独立 session** 写入：
   - 业务回滚不影响审计（已验证 422/401 失败操作同样落库）
   - 审计写入失败也不影响业务（全包裹 try/except）
   - 代价：非原子提交，响应后进程立即被 kill 可能丢一条（已注释说明取舍）

2) 采集方式：中间件自动采集写操作 + 导出/下载/打印这类「读但敏感」的 GET。
   路径段推导 module/action/target_id。不做手写埋点，因为手写必然漏 ——
   task_logs 只有 4 处写入点就是前车之鉴。

3) 增量价值：新增 request_id 字段，与 core/logging.py 的结构化日志打通，
   凭一个 ID 就能从审计记录直接跳到那一次接口日志。MOM 无此字段。

4) 敏感信息：details 经 sanitize_details 递归剔除 password/token/secret 等键；
   中间件不读请求体，登录明文密码不会落库（已断言表内无密码痕迹）。

配套改动：
- core/roles.py：角色常量与 is_admin 收敛为单一事实来源。此前同一份
  「管理员角色」规则散在 task_service、products.py 内联判断和前端
  constants/task.ts 三处，已因此发生过「移动端漏判 SUPERVISOR 误挡主管」。
  task_service 改为从 core.roles 导入同名常量，保持既有引用可用。
- core/deps.py：抽出 require_roles/require_admin 可复用依赖，替代内联判断。
- main.py：500 响应显式补 X-Request-ID 头 —— 该响应由 ServerErrorMiddleware
  生成，位于 RequestContextMiddleware 外层，中间件没机会写头。
- auth.py：登录校验前把「尝试的账号」写入 request.state，使登录事件
  （含失败登录）可归属到人，可用于追踪暴力破解。

验证：本地起 PostgreSQL 17 + 迁移后跑端到端测试，32/32 通过
（TestClient 每个请求新建事件循环，与模块级 asyncpg 连接池冲突会报
 "got Future attached to a different loop"，故改用 httpx.AsyncClient +
 ASGITransport 单循环；生产 uvicorn 单循环无此问题）。
 2026-09-21 02:23:19 +00:00
openhands
4454047ce3 fix: 修复任务分页总数错误 + 补齐可观测性基建 
分页总数（#5）：
- get_all_tasks 的 total 原为 len(flat_tasks)（当前页条数），移动端
  「我的任务」用 tasks.length < total 判断 hasMore，首页满员时恒为
  false，列表永远停在第一页 20 条。改为独立 COUNT 查询（与
  notifications.py 已有写法保持一致）。

可观测性（#9）：
- 新增 core/logging.py：单行 JSON 结构化日志 + request_id/user 上下文
  注入；零第三方依赖；接管 uvicorn 自带 handler 避免格式绕过。
- 新增 core/middleware.py：RequestContextMiddleware 生成/透传
  X-Request-ID 并回写响应头，输出含耗时/用户的结构化访问日志。
- 新增 core/health.py：拆分存活/就绪探针。/health/live 不触依赖；
  /health/ready 探主库，不可用返回 503；MOM 挂掉仅降级不摘流量。
- main.py：全局异常处理器只把堆栈写日志，响应体仅回 request_id；
  接入可选 Sentry（未装 SDK 时静默跳过）。
- auth_service：解析 Token 后写入 user 上下文，日志自动带操作人。

注：异常处理器由 ServerErrorMiddleware 调用，此时 contextvar 已被重置，
故 request_id 同时写入 request.state（由 ASGI scope 承载）再读取。

已用 TestClient 验证：探针状态码/检查项、X-Request-ID 透传与生成、
500 响应携带可对账的 request_id 且不泄露堆栈。
 2026-09-21 01:57:20 +00:00
duxingchen
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
duxingchen
1e6c006360 feat: MES/MOM 出入库状态解绑与直接完结通道（后端契约 + 移动端） 
- TaskTransferRequest 新增 finish_directly 开关：闭环当前任务但不产生任何下游任务，
  产品 overall_status 保持原样，工人无需再借道「入库(virtual_warehouse)」来关闭任务，
  从根源上避免产品被误标「待仓库收货」而卡住 MOM 对账
- 空 assignees 分支加防呆校验：想直接完结必须显式传 finish_directly=true，
  杜绝漏填导致「转交」静默退化成「直接完结」的丢件级隐患
- 直接完结跳过 _mark_after_sales_if_reactivated：不产生新任务即不构成「回流返厂」信号，
  否则已出库设备的正常收官会把产品误翻成售后机（该标志单向不可回退）
- 补齐直接完结的独立响应文案，不再拼出「已创建 0 个下一道工序任务「None」」
- 移动端转交弹窗改为「转交个人 / 入库 / 直接完结」三选一互斥
 2026-09-17 14:07:02 +08:00
duxingchen
71e660b428 feat: 驳回图片改为选填，驳回原因/转交备注落库留痕 
业务调整：车间驳回不必须拍照（编号错误、选错工序等场景无需照片举证）。

- schemas/task.py: TaskRejectRequest.images 由必填(min_length=1)改为
  default_factory=list，保留 max_length=9 与 URL 总长保护；reason 增加
  mode="before" 的 strip 校验器，堵住纯空格凑长度绕过 min_length 的口子
  （顺带保证落库的 reject_reason 不带首尾空白）
- task_service.py: 驳回时把原因+图片写入 TaskRecord 挂到被驳回任务下，
  修复前端时间线看不到驳回详情的问题；转交时把交接备注也挂一条记录到
  下家任务，补齐接手人的上下文视角
- task_service.py: create_task / receive_task 写入 overall_status 后调用
  sync_product_status 对齐 status 字段
 2026-09-15 10:57:35 +08:00
duxingchen
2de95799c6 feat: 售后回流判定与工序选项隔离守卫(建单/接收/转交) 2026-09-14 14:49:34 +08:00
duxingchen
3568d17865 fix: 转交时动态推导task_type,避免协助分支转交被误升为主线 2026-09-14 14:49:26 +08:00
duxingchen
3019653dfa refactor: 宏观状态统一(待仓库收货/已入库)废弃"在库"; WIP矩阵返回product_name并新增下钻明细 2026-09-02 10:38:49 +08:00
duxingchen
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
duxingchen
477a187fc1 fix(操作统计): 上传备注改为按任务负责人归因，历史数据可回溯 
- 备注统计不用 task_logs(历史无record日志)，改为 task_records 按任务 assignee 归因
- 排除系统自动生成的备注(以'['开头的接收/转交/撤回等)，只计手动上传
- 移除 add_task_record 冗余的 record 日志(不再用于统计)
- 不改数据库，历史182条备注也能正确归属到人
 2026-08-28 13:26:26 +08:00
duxingchen
b85188e625 feat(backend): 新增 /dashboard/user-operations 人员操作统计接口 
- add_task_record 补 action_type=record 日志，使上传备注可统计到人
- get_user_operations 按人聚合 接收(receive)/转交(complete)/上传备注(record) 次数，时间筛选，中文名映射
- 复用 get_display_names，不新增数据库字段
 2026-08-28 13:14:09 +08:00
duxingchen
2170e2e9cf fix: 转交通知中product_sn始终为空 — product查询移到通知循环之前 
根因: transfer_task中 product_result 查询在通知创建循环之后
     通知内容 product_sn 引用未初始化的 product 变量 → 始终为空字符串
修复: 将 product 查询提前到 flush() 之后、通知循环之前
 2026-08-12 17:33:32 +08:00
duxingchen
e7bfdc261b fix: TaskRecord也加入管理员代办审计标记 — 看板最新动态可见代理操作 
新增 _admin_proxy_note() 辅助函数
receive/transfer 的 TaskRecord.remark 自动拼接 [管理员xx代办]
这样看板\最新动态\列就能显示管理员代操作记录
 2026-08-12 17:11:07 +08:00
duxingchen
1fdc607c07 feat: 管理员代工模式 — 前端权限放开 + 后端审计留痕 
前端:
  - WorkspaceArea 新增 currentUserRole prop
  - isAssignee/canRecall: SUPER_ADMIN/SUPERVISOR 上帝视角直接放行
  - 管理员代操作时显示黄色提示条: 正在以管理员身份代[原负责人]操作
  - detail.vue: loadCurrentUser 提取并保存 user.role

后端:
  - _create_task_log 新增 task_assignee_id 参数
  - operator_id!=task_assignee_id 时自动拼接 [管理员xx代办操作]
  - 12处调用点全部传入 task_assignee_id
  - receive_task 位置赋值确认为 task.assignee_id(非 operator_id)
 2026-08-12 15:24:50 +08:00
duxingchen
cc199081f9 perf: CTE任务树加载器 + MOM跨库查询缓存 
消除两个核心N+1性能瓶颈：

1. CTE任务树加载器 (task_tree_loader.py)
   - PostgreSQL Recursive CTE一次性加载完整任务树
   - 无论树深度多大，仅2条SQL（CTE + records selectinload）
   - set_committed_value安全注入，避免Session脏数据
   - 修复add_task_record双重加载问题
   - 移除get_all_tasks中冗余的selectinload(child_tasks)

2. MOM跨库查询缓存 (mom_cache.py)
   - 零依赖TTL内存缓存（threading.RLock + time.monotonic）
   - 参数化ANY(:user_ids)替代OR拼接LIKE（防注入）
   - get_all_products中3次调用共享缓存，2h TTL内零跨库查询
 2026-08-12 12:03:02 +08:00
duxingchen
991d713777 feat(backend): 新增留言通知 — add_task_record 自动推送给任务负责人 
触发条件:
- 有人对任务添加流转记录(留言/备注)
- 任务有 assignee_id
- 留言人 != 任务负责人 (不给自己发通知)

通知内容:
- title: 💬 收到新留言
- content: 产品[SN]的「任务名」有新留言：{前30字摘要}
- type: COMMENT

额外:
- Notification 模型新增 NOTIFY_COMMENT 常量
- 前端 notify 页新增 COMMENT 图标(💬)和标题(收到新留言)
 2026-08-11 18:17:52 +08:00
duxingchen
88dc7381f6 fix(backend): 权限漏洞修复 + 业务逻辑审查修复 
1. 宏观状态越权修复 (products.py + product_service.py):
   - update_overall_status 增加权限校验：仅 SUPER_ADMIN 或当前操作该产品主线任务的人可修改，否则 403

2. 任务撤回越权修复 (task_service.py + tasks.py):
   - recall_task 增加校验：操作人必须等于上游任务负责人（谁发出的谁撤回），否则 403
   - 管理员 (SUPER_ADMIN/SUPERVISOR) 直接放行

3. 驳回上游溯源修复 (task_service.py - reject_task):
   - 将 TaskLog (action_type=create) 提升为优先溯源方式，解决协助分支转交后驳回找不到正确发起人的 Bug
   - 保留 parent_task.assignee_id + task.assignee_id 两级兜底

4. complete_task 父节点继承修复:
   - 修复 task_type == 'MAIN' 永不匹配的 Bug（模型无此值）
   - 改为 not parent_task_id or task_type in (TRANSFER, RECOVERY)
 2026-08-11 15:05:30 +08:00
duxingchen
d40a8d480e fix(backend): end_task 和 complete_task 补齐权限校验 
- end_task 新增 operator_role 参数 + _check_permission 调用
- complete_task 新增 operator_role 参数 + _check_permission 调用
- 两个端点均注入 current_user Depends(get_current_user)
- 非任务负责人且非管理员/主管调用时返回 403
 2026-08-11 10:13:40 +08:00
duxingchen
de47d27cfb fix(backend): _recalc_product_location 修复 func.or_() → or_() 
func 是 SQL 函数调用（如 func.now()），不能替代 WHERE 条件中的 or_ 运算符。
这会导致结束协助分支时 SQL 抛错 500。
 2026-08-11 10:05:13 +08:00
duxingchen
718e205f53 feat(backend): 完工转交智能父节点继承算法 
- complete_task: MAIN转交保持平级(parent_task_id)，SPAWN转交认当前为父(task.id)
- 基因严格继承: task_type不会篡位成MAIN
 2026-08-11 10:02:01 +08:00
duxingchen
e326f8d311 fix: 修复任务完工/结束 500 + 后端基因继承 
- 移除 task.child_tasks 的 ORM 属性直接赋值（导致 SQLAlchemy 状态机崩溃）
- complete_task 创建 next_task 时补上 task_type=task.task_type 基因继承
 2026-08-10 17:36:54 +08:00
duxingchen
2880ea6df7 fix: Grid回退grid-cols-12精确对齐+分组标题按device/order切换+宏观状态receive/transfer只主线 2026-08-10 10:58:33 +08:00
duxingchen
4854eb626e feat: 宏观状态只同步主线+删除5s倒计时+序列号确认+分组切换(订单/设备)+序列号列 2026-08-10 10:37:56 +08:00
duxingchen
ad9fb8d37e refactor: 位置回溯极简—只跟主干任务(WIP>PENDING>COMPLETED),无视协助分支 2026-08-09 18:49:59 +08:00
duxingchen
45b5376537 fix: 三致命Bug—macro_status预计算+排除已完工脏读+flush落盘+递归深度限制10 2026-08-09 18:23:55 +08:00
duxingchen
f33396b9f1 fix: 位置回溯父任务优先 + Tab筛选改为本地calcProductStatus过滤 2026-08-09 18:10:13 +08:00
duxingchen
3c4c16a1cc fix: 四Bug—权限互斥+中文姓名+记录弹窗+后端位置回溯(含RecordsModal) 2026-08-09 17:55:40 +08:00
duxingchen
65ff05fb2f feat: 状态渲染修复+中文姓名映射+SUPERVISOR/SUPER_ADMIN权限控制(前端+后端) 2026-08-07 17:26:14 +08:00
duxingchen
b71c5a2d07 feat: 双Token认证(Access 2h/Refresh 7d) + 通知系统(转交/驳回自动推送) 2026-08-07 11:44:04 +08:00
duxingchen
6a79e21302 闭环修复: transfer/spawn/receive补TaskRecord + reject加task_type + branchLabel只对SPAWN编号 2026-08-06 13:14:26 +08:00
duxingchen
0d323e8181 血缘锚定法: task_type字段+迁移+三大接口写入+TreeCanvas基于task_type布局 2026-08-06 13:03:25 +08:00
duxingchen
e5e2a395e7 撤回链式接力: CANCELED后生成WIP子任务还给操作人+TreeCanvas CANCELED视为串行换行 2026-08-06 12:53:23 +08:00
duxingchen
616638a6c8 撤回改为CANCELED状态标记+TaskRecord留痕+TreeCanvas灰度渲染+全部状态映射更新 2026-08-06 12:51:40 +08:00
duxingchen
eb97c12bed 修复撤回: 移除parent_task_id空校验+兼容无父任务场景(仅删除) 2026-08-06 12:39:47 +08:00
duxingchen
58cb9a23ef 修复撤回: transfer新任务parent_task_id=task.id(溯源链) + canRecall放宽(兼容旧数据) 2026-08-06 12:38:26 +08:00
duxingchen
67755c7847 修复撤回500: 先删task_logs+task_records再删task,加delete import 2026-08-06 11:41:45 +08:00
duxingchen
57884d7baa 撤回转交: recall接口删除子任务恢复父WIP + 前端canRecall判断 + 红色撤回按钮 2026-08-06 11:39:22 +08:00
duxingchen
b2cfa3871e 取消转交的协助分支阻塞: transfer_task移除_check_children_done,仅end_task保留 2026-08-06 11:29:58 +08:00
duxingchen
ef9e5bbae5 修复get_all_tasks: 改用_to_flat_response(不递归children)彻底消除MissingGreenlet 2026-08-06 11:19:19 +08:00
duxingchen
9846dd6c8f 修复: MissingGreenlet_product访问try/catch + spawn_subtask不再覆盖overall_status 2026-08-06 11:16:07 +08:00
duxingchen
e183ea5583 工业级重构: 用户Grid选择+工序由接收人定+隐藏结束按钮(次分支卡片内结束)+蓝图网格背景 2026-08-06 09:52:21 +08:00
duxingchen
eb52e2fd48 修复: create_task同步current_location_id到接收人 + receive_task兜底同步产品位置 2026-08-06 09:12:07 +08:00
duxingchen
f3fb000bda 产品宏观状态自动同步: create_task/transfer_task/spawn_subtask均更新overall_status 2026-08-06 09:06:07 +08:00
duxingchen
f665cf7e24 紧急修复: transfer中real_assignees→real_branches变量名 + SpawnRequest BaseModel导入 2026-08-05 18:16:07 +08:00
duxingchen
b547844dca 并发模型: spawn派发协助分支 + 转交简化为单线 + 子分支未完成拦截(409) 2026-08-05 18:01:14 +08:00
duxingchen
21aa608db3 工艺节点树: 新增结束分支(终止)接口 + 前端🏁结束分支按钮 + WIP可无下游完结 2026-08-05 16:37:05 +08:00
duxingchen
e2d9590c48 修复remark丢失(_to_response漏字段) + UI重构swiper专注卡片看板 2026-08-05 16:35:14 +08:00
duxingchen
4ee3cb7552 紧急修复: get_all_tasks移除parent_task_id过滤 — 子任务也能出现在我的任务列表 2026-08-05 16:30:45 +08:00
duxingchen
9978714d40 紧急修复: receive_task语法错误 — raise HTTPException括号未闭合导致后端启动失败 2026-08-05 16:25:34 +08:00
duxingchen
71e8eeb7e8 权限: receive/reject校验assignee_id匹配 + 前端myActiveTask只显示本人任务 + 403处理 2026-08-05 16:21:27 +08:00