|
|
cfcfca7269
|
feat(分组权限): 业务分组模型 + DataScope 判定 + 列表接口接入
第一阶段：模型 → 判定 → /auth/me → 列表。统计接口与前端管理页随后。
1) 模型与迁移（head 从 k1l2m3n4o5p6 推进到 l1m2n3o4p5q6）
· business_groups 组定义，parent_id 表达「大组 > 小组」
· business_group_phases 可见范围，独立成表以支持多选 —— 需求要求
「范围可配置、不要写死」，单列存不下多个 phase
· business_group_members 成员，一人可属多组（这是「同时看生产+维修」的实现）
只建表、不写种子数据，所以可以先部署代码再建组。
2) DataScope 判定模块（app/services/data_scope_service.py）
全仓库唯一的权限谓词来源，业务代码里不准再出现 lifecycle_phase 过滤。
两条红线照抄部门隔离的教训：
· None(不限) 与 frozenset()(空) 语义相反，绝不共用一个哨兵值
· 空集合必须显式 false() —— SQLAlchemy 对 in_(()) 生 成 IN (NULL)，
一旦退化成不过滤就是全量泄漏
解析优先级：SUPER_ADMIN 硬放行（不可被分组覆盖）
> 显式分组（分组优先于角色）
> 未分组 SUPERVISOR 默认全厂
> 未分组普通用户
3) 过渡期开关 DATA_SCOPE_UNGROUPED（默认 ALL）
直接上严格模式会让所有未分组工人当场看不到自己的任务、现场停摆。
默认 ALL 先放行并打 WARNING 记录「谁还没分组」，配好组后再改 NONE。
4) /auth/me 返回 scope，phase 中文标签由服务端下发
—— 前端已有两份 phase 词表副本，不再加第三份。
5) 列表接口接入
· get_all_products：过滤加在 offset/limit 之前（其下有 6 段基于 product_ids
的批量预计算，过滤晚了等于算完再丢）
· get_all_tasks：谓词进【共享 filters】，保证 count 与 select 两条独立语句
同时生效，否则 total 与实际页不一致、移动端 hasMore 判断跟着错
· 扫码 get_product_by_serial 刻意不过滤，理由写死在 docstring 里
实测：空 scope 生成 false、受限 scope 生成 JOIN + IN 谓词；
/products 返回 2 条、/tasks 的 total 与 returned 一致。
|
2026-09-21 17:07:46 +08:00 |
|
|
|
f9f3d90f96
|
fix: 二维码接口去鉴权（修复破图）+ 产品序列号加部门前缀
1) 二维码破图
/products/qrcode/{sn} 带了 Depends(get_current_user)，而前端是用
<img src="/api/v1/products/qrcode/{sn}"> 引用它的 —— <img> 无法携带
Authorization 头，请求必然 401，页面上就是破图（同时刷大量 401 审计）。
该接口不查库、只把调用方传进来的字符串渲染成二维码，没有数据泄露面，
故去掉鉴权。刻意不做 ?token= 兜底：JWT 进 URL 会渗进访问日志、浏览器
历史与 Referer，比它想解决的问题更糟。
实测：HTTP 200 / image/png / 300x300。
2) 序列号部门前缀
新增 config.SERIAL_PREFIX（LICA 为 "L"），counter_service 生成
{前缀}{15 位 HEX}，总长仍严格 16 位 —— products.serial_number 是
String(16)，前端 TaskTreeViewer / ManualInput / ScanPage 多处按 16 位
校验，不能改总长。IRIS 实例该值为空串，格式保持原样。
实测 LICA 生成 L000000000000002。
前端本就兼容带字母的序列号：TaskTreeViewer 的占位符示例就是
X20260801000001，ScanPage 的 replace(/[^a-zA-Z0-9]/g,"") 也不会滤掉 L。
|
2026-09-21 16:34:56 +08:00 |
|
|
|
a2940d265d
|
fix: 超管跨部门放行 —— 修正登录部门过滤过严
原实现把所有账号一律收敛到 department = ORG_DEPARTMENT，导致 IRIS 的
超级管理员登不进 LICA 实例。需求本意是「超管不拦截，其余角色只能本部门
登录」，实现时把超管的豁免一起去掉了。
改为：
WHERE username LIKE :pattern
AND (department = :dept OR role = 'SUPER_ADMIN')
role 取自 app/core/roles.py::SUPER_ADMIN，不新增硬编码字符串。
已用 MOM 真实数据验证：
duxingchen / zhuxiangning（IRIS 超管） -> 放行
xingyouwu / sunxia（LICA 超管） -> 放行
weihuijun（LICA 普通）、gaoxue（LICA 主管） -> 放行
zhangxinxin（IRIS 普通）、renlixin（IRIS 主管）-> 仍拒
|
2026-09-21 16:17:52 +08:00 |
|
|
|
347b7b6a68
|
feat: LICA 部门独立实例 — 组织隔离与端口/标识改造
派生自 IRIS 实例的 feature/ai-audit-update @ 192c8ee，在同一台机器上独立运行。
隔离机制（开关集中在 app/core/config.py 的 ORG_DEPARTMENT / MATERIAL_CATEGORY_PREFIX）：
- 登录：sys_user 查询增加 department 条件，非本部门账号一律 401
- 人员列表：服务端钉死部门、忽略客户端传参；删除「异常退回全表」的降级分支
- 物料：groups 与 items 都增加 category LIKE 'LICA/%' 前缀过滤
- 人员操作统计：把硬编码的 department='IRIS' 改为配置项
物料为什么用前缀而不是 LIKE '%LICA%'：
MOM 里存在 171 条 IRIS/成品/LICA/...（无人机/野外便携/高塔监测等），
模糊匹配会把这些 IRIS 物料漏给 LICA。实测前缀匹配命中 795 条 / 5 个分组。
部署隔离：
- 端口 8030/8031/8032，容器名 lica_*，卷 lica_pgdata（与 IRIS 完全独立）
- 服务名改为 lica_backend，避免在 projects_default 网络上与 IRIS 的 backend
重名 —— 否则将来任何一方写 http://backend:8000 会随机打到另一个部门
- SECRET_KEY 重新生成：实测两边 token 互不通用（双向 401）
客户端标识（不改会导致两个部门的客户端互相覆盖）：
- Tauri identifier 改 com.lica.production（否则桌面端互相覆盖安装，且共用
WebView 数据目录会让 track_admin_token 串号）
- uni-app appid 改 __UNI__D2F4A19（否则同机 APK 互相覆盖、wgt 热更新串号）
- uni-app 地址端口 8011 → 8031（收敛在 utils/config.js 单一来源）
- sync-watch.sh 的 DST 指向 LICA 专属 HBuilderX 目录（否则会把源码灌进 IRIS 工程）
排除项：未复制 deploy.sh / deploy_full.sh / docker-compose.prod.yml ——
它们写死了 IRIS 的生产服务器，误跑会覆盖线上系统。
|
2026-09-21 16:10:52 +08:00 |
|
|
|
3286a11bc7
|
chore: fork from IRIS track 供 LICA 部门独立运行
- 复制来源: /home/yueli/track @ 192c8ee (feature/ai-audit-update)
- 组织隔离目标: LICA
- 端口规划: 前端 8030 / 后端 8031 / 数据库 8032
- 已排除 deploy.sh、deploy_full.sh、docker-compose.prod.yml（IRIS 生产发布脚本）
- 已排除工作区未提交改动，取干净的 192c8ee 状态
|
2026-09-21 15:56:52 +08:00 |
|
