|
|
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 |
|
|
|
04eb87b091
|
fix: 访问日志的 user 字段恒为 null —— 改用 request.state 跨 task 传递
上一提交(4454047)的 RequestContextMiddleware 通过 contextvar 读取 user,
但 Starlette 的 BaseHTTPMiddleware 用 anyio start_soon 把下游放进新 task
执行,而 asyncio 每个 Task 创建时会复制 context —— 路由内 set 的
contextvar 不会回流到中间件,导致访问日志的 user 永远是 null。
修复:
- get_current_user 同时写 contextvar(供请求任务内业务日志用)与
request.state(由 ASGI scope 承载,跨 task 可见),并带上
display_name / role 备用。
- 中间件 _log_access 改为优先读 request.state.audit_user。
验证(TestClient + 解析最终 JSON 输出,而非读 record 属性):
- track.access 日志 user=zhangsan01(经 request.state)
- 请求任务内 track.service 日志 user=zhangsan01(经 contextvar)
- 两者 request_id 一致;X-Request-ID 透传正常
|
2026-09-21 02:11:41 +00:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
f22eae315f
|
fix: 售后回流口径统一 — 状态双字段同步、工序名归一、标签配色
产品存在 overall_status 与 status 两个状态字段,此前各写入点各写一份映射、
甚至只改 overall_status 不改 status,导致回流设备(product.status 停留在
OUTBOUND)污染看板统计口径。
- lifecycle.py: 把映射表收敛为单一来源 overall_to_product_status /
sync_product_status;新增 normalize_after_sales_step,将售后设备沿用生产
阶段写法的历史工序名(测试/维修)折算到售后区独立工序名
- product_service.py: 删除本地 _OVERALL_TO_STATUS 副本,改用共享函数
- dashboard_service.py: WIP 矩阵补出 lifecycle_phase 列,活跃任务判定
(is_active) 提前到所有终结态判定之前,避免残留 OUTBOUND 被误判为完结
- scripts/fix_product_status.py: 历史数据修复脚本(一次性)
- constants/task.ts: 售后工序标签由红色改紫色 —— 红色在本系统是「驳回/危险」
语义色,售后只是另一条流转支线,用红色会让操作员误以为设备报错
|
2026-09-15 10:57:29 +08:00 |
|
|
|
b9f9b897a1
|
feat: 新增产品生命周期阶段字段lifecycle_phase与售后工序词表
|
2026-09-14 14:49:34 +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 |
|
|
|
ad4b55dece
|
feat(工作日): 新增工作小时计算工具 + 节假日表与管理接口
- time_utils 新增 to_beijing(统一naive按UTC转北京时间) + working_duration_hours(排除周末/节假日)
- Holiday 模型 + alembic 迁移建 holidays 表
- GET/POST/DELETE /holidays 节假日管理接口,可随时配置放假日期
|
2026-08-28 15:08:05 +08:00 |
|
|
|
c3f3a5e291
|
fix: 看板动态时间改为北京时间 + 操作人显示中文姓名
1. 时区修复:
- database.py: PG连接池会话级设置 TimeZone=Asia/Shanghai
- dashboard_service.py: 格式化时间显式 astimezone(BEIJING_TZ)
- 兜底: tzinfo为None时默认当作北京时间处理
2. 操作人中文姓名:
- 收集所有operator_id → 调用mom_cache批量翻译
- 优先中文姓名 → 英文用户名兜底
- operator_id为None时不再显示"系统",留空
|
2026-08-12 13:28:38 +08:00 |
|
|
|
d59f732a0e
|
fix: 数据库会话事务安全兜底
get_db() 依赖注入增加 try/except/rollback/finally:
- 请求处理中发生异常时自动 rollback
- 无论成功或异常,finally 中确保 close 释放连接
- 防止异常导致连接泄漏或脏事务残留
|
2026-08-12 12:04:45 +08:00 |
|
|
|
69f3e35d14
|
fix: Dashboard统计数据修复 + 生产环境SECRET_KEY强制校验
1. Dashboard统计Bug修复
- Task统计改用TASK_STATUS_PENDING/WIP/COMPLETED大写常量
- 旧代码使用小写"pending"/"in_progress"永远匹配不到数据
- 修复后tasks_pending/tasks_in_progress/tasks_completed返回真实值
2. 生产环境SECRET_KEY强制校验
- 新增model_validator:DEBUG=False且SECRET_KEY为默认值时抛出ValueError
- 阻止使用默认密钥部署到生产环境
|
2026-08-12 12:03:07 +08:00 |
|
|
|
b71c5a2d07
|
feat: 双Token认证(Access 2h/Refresh 7d) + 通知系统(转交/驳回自动推送)
|
2026-08-07 11:44:04 +08:00 |
|
|
|
82f474f71f
|
chore: 基础设施 — 阿里云源、北京时间、HEX计数器、打印机配置
|
2026-08-05 14:00:13 +08:00 |
|
|
|
2b967afbf6
|
chore: 更新后端依赖,初始化数据库迁移与 MOM 外部系统连接
|
2026-08-04 17:09:33 +08:00 |
|
|
|
895fed6ac3
|
chore: 添加 .gitignore 并移除敏感/缓存文件
- 添加 .gitignore (Python __pycache__, .env, .idea, node_modules 等)
- 从追踪中移除 backend/.env, frontend/.env (密钥文件)
- 从追踪中移除 __pycache__/ 目录 (编译缓存)
- 从追踪中移除 .idea/ (IDE 配置)
|
2026-08-04 17:03:17 +08:00 |
|
|
|
17105dc9c2
|
初始提交:项目基础结构
- backend: FastAPI 后端服务 (Python)
- frontend: React + Tauri 前端应用
- docker-compose.yml: 容器编排配置
|
2026-08-04 10:05:59 +08:00 |
|