|
|
5095756571
|
fix(分组): 把超管排除在分组之外 + 添加成员改用带搜索的下拉
1) 超管不进分组
超管的数据范围是硬编码全厂（resolve_data_scope 规则 1），业务分组对他
根本不生效。把他放进成员名单会造成两处矛盾：
· 界面上「他在这个组里」暗示他受该组约束，但实际不受；
· 若再给他打组长标记，会出现「组长却不受组范围限制」的怪状态。
所以：
· member-candidates 的 SQL 加 `COALESCE(role,'') <> 'SUPER_ADMIN'`
（LICA 19 人 → 17 人）
· add_member 再挡一道并给出明确原因，防止绕过界面直接调接口
· _is_super_admin_account 在 MOM 查询失败时**保守当作超管拦下** ——
误拦只是加不进去，误放会留下脏数据
2) 添加成员的下拉改用 antd Select
原先是原生 <select>：LICA 近 20 人，展开会整屏铺开、且不能搜索，又长又难选。
改为带 showSearch 的 Select（按姓名或账号过滤，optionFilterProp=label），
并在未选人时禁用「添加」按钮，避免无意义报错。
实测：
候选人数 19 → 17，超管已不在列表中
直接 POST 加 sunxia / xingyouwu → 400 并给出原因
普通成员 duwensheng 加入 → 201，移出 → 204（对照组正常）
|
2026-09-21 17:41:17 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
