duxingchen/track-LICA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
11 Commits 1 Branch 0 Tags
15097baa2b1ed7fbe04c977acd24ffd0ca639f89
Commit Graph

5 Commits

Author SHA1 Message Date
duxingchen
15097baa2b feat(权限): 业务分组对全员开放（操作分层）+ 操作审计仅超管可见 
需求：业务分组开放给所有人，主管可操作、其余人只读；操作审计前端不显示。

⚠️ 这里有个必须收窄的边界：按数据范围规则，被分进组的 SUPERVISOR 会从
「全厂」降级为只看本组。若允许他改可见范围，他把自己那组改成「生产+售后」
就恢复全厂视野；若允许建组，他新建一个组再把自己塞进去，同样绕过。
**「能管成员」与「能配范围」必须分开** —— 前者安全（组长给自己加组会被
唯一约束挡住、移出自己只是失去权限），后者是提权入口。

因此分层如下：

  | 谁               | 看           | 改                                 |
  |------------------|--------------|------------------------------------|
  | SUPER_ADMIN      | 所有组       | 全部（建/改/删组、配范围、管成员） |
  | 主管 / 本组组长  | 自己所属的组 | **仅本组成员**（加人/移人/设组长） |
  | 普通成员         | 自己所属的组 | 无（只读）                         |

后端（groups.py）：
· 去掉路由级的 require_roles(SUPER_ADMIN)，改为逐端点校验
· list_groups / get_group：非超管只返回自己所属的组；看别组详情 403
  （连「这个组存在但你没份」都不暴露，避免被拿来推测组织架构）
· create/update/delete：_require_super —— 这三个 + 配范围是提权入口
· add/update/remove member：_can_manage_members（超管 / 主管 / 本组组长）
· GroupOut 新增 can_manage_members / can_manage_group / is_my_leader
  —— 由服务端算好下发，前端不按 role 自行推导（组长身份是按组算的）

前端：
· AdminGroupsPage 去掉整页超管门禁，改为按能力显示按钮：
  无权限时「组长」列退化成纯展示而非可点按钮
  没有任何组时给「你还没有被分配到任何业务分组」的引导提示
· AdminLayout 的 MENU 支持 superOnly 标记，「操作审计」只对超管显示
  （后端 /audit/* 本就挂了 require_admin，这里只是不给入口，
   否则普通用户点进去只会看到一堆 403）

实测（四类账号）：
  建组/改范围：仅超管通过，其余全 403
  管成员：超管/主管/本组组长通过；非本组 403；跨组组长 403
  可见性：主管未分组看到 0 个组、维修组长只看到维修大组、生产组员只看到生产小组
  详情页能力标记正确下发；越权查别组详情 403
 2026-09-21 17:38:07 +08:00
duxingchen
3c1c5d6fb5 feat(分组权限): 分组管理接口 + 管理页 + 端到端验收 
后端 endpoints/groups.py（**仅 SUPER_ADMIN**）：
· 组的 CRUD（两级，子组不配范围则继承父组 —— 生产大组配一次，下面的
  生产/测试小组都不用再配）
· 成员增删 / 设组长 / 候选人下拉（复用 MOM 查询口径，部门已钉死为 ORG_DEPARTMENT）
· **删组仅限空组**：级联删是一次静默的批量权限变更，误点一下一批人就突然
  看不到数据了；强制「先移人再删组」多一步，但出错时是可见的
· 停用组的语义写死在接口文档：成员**立即**退回未分组状态

为什么只有超管能管分组（不是偏好，是必须）：
  被显式分进组的 SUPERVISOR 会从「全厂」降级为只看本组；若允许主管管理分组，
  他把自己移出组就能恢复全厂视野 —— 这是一条现成的提权路径，分组对他无效。

前端：
· AdminGroupsPage：组列表 + 可见范围勾选 + 成员管理 + 组长标记 + 二次确认
· AdminLayout 加菜单项，页头显示数据范围徽标 —— 空范围（未分组）用橙色显眼
  提示，否则用户看到空列表会以为系统坏了，这是最难排查的一类反馈
· AuthContext 登录后补拉一次 /auth/me 拿 scope（登录接口不查库、不返回它）
· constants/task.ts 新增 isSuperAdmin，不手写 === 比较

端到端验收（实测）：先造 1 生产 + 1 售后产品，然后
  生产组员 → 1 条，全 PRODUCTION；范围经「生产小组 → 生产大组」继承而来
  维修组员 → 1 条，全 AFTER_SALES
  超管     → 2 条，全量
  任务列表 total 与 returned 一致（验证 count/select 双过滤）
  扫码跨组仍 200（符合「能看、不能操作」的既定决策）
  停用维修大组 → 成员立即退回未分组
  上述测试数据已还原
 2026-09-21 17:10:33 +08:00
duxingchen
f04c7e0b99 perf(创建产品): 物料手风琴虚拟滚动 + memo 化，并修掉打开时的重复请求 
反馈是展开物料列表卡。实测后端并不慢：/materials/groups 10~18ms，
生产配件 684 条 / 107KB 的 items 只要 16ms，MOM 侧纯 SQL 1.43ms，
category 上还有 idx_base_category 索引 —— 瓶颈全部在前端渲染。

1. Table 既不分页也没虚拟化，LICA/生产配件 的 684 条要一次性建出近 700 个
   表格行。改为 virtual + scroll={y:240, x:600}，只渲染可视区那十几行。
   （antd 的 virtual 要求 scroll.x/y 都是数字，列宽因此显式指定。）
2. collapseItems 每次重渲染都重建全部 Table 元素，而每个分组在「开始加载」
   和「加载完成」各触发一次 forceRefresh —— 点「全部展开」就是十几次全量
   重建，这才是卡顿主因。改用 useMemo；tick 必须进依赖，因为 groupCache /
   groupLoadingMap 都是 ref。
3. columns 与 handleSelect 一并 memo 化，否则第 2 条 memo 每次都会失效。
4. 打开对话框时 useEffect([open]) 与 useEffect([keyword]) 会各请求一次
   /materials/groups。用 lastSearchedRef 记录「上次已搜索的词」，跳过
   setKeyword("") 重置造成的那次重复请求。
 2026-09-21 16:24:36 +08:00
duxingchen
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
duxingchen
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